git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Pratyush Yadav <me@yadavpratyush.com>
Cc: harish k <harish2704@gmail.com>,
	git@vger.kernel.org, David Aguilar <davvid@gmail.com>
Subject: Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts
Date: Fri, 4 Oct 2019 10:49:52 +0200 (CEST)
Message-ID: <nycvar.QRO.7.76.6.1910041046000.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20191003214422.d4nocrxadxt47smg@yadavpratyush.com>

Hi Pratyush,

please don't top-post on this list (yet another of these things
requiring extra brain cycles in the mailing list workflow).

On Fri, 4 Oct 2019, Pratyush Yadav wrote:

> Hi Harish,
>
> Thanks for the patch. Unfortunately, it seems your mail client messed up
> the formatting, and the patch won't apply. I'm guessing it is because
> your mail client broke long lines into two, messing up the diff.
>
> We use an email-based workflow, so please either configure your mail
> client so it doesn't munge patches, or use `git send-email`. You can
> find a pretty good tutorial on sending patches via email over at [0].
> The tutorial is for git.git, but works for git-gui.git as well.

Ah, well. Mailing list-based workflows are so easy, amirite? They are so
welcoming and inclusive, yes?
</sarcasm>

> If you feel more comfortable with GitHub pull requests, please take a
> look at Gitgitgadget [1]. Johannes (in Cc) has used it recently to send
> patches based on the git-gui repo (AFAIK, it was originally designed
> only for the git.git repo). Maybe ask the folks over there how they do
> it.

Harish, it is actually relatively easy to use GitGitGadget: just add a
remote like this:

	git remote add gitgitgadget https://github.com/gitgitgadget/git
	git fetch gitgitgadget git-gui/master

and then rebase your patch on top of that branch:

	git rebase -i --onto git-gui/master HEAD~1

Then force-push your branch to your GitHub fork of git.git and open a
Pull Request at https://github.com/gitgitgadget/git/pulls, targeting
git-gui/master.

GitGitGadget will welcome you with a (hopefully) helpful message ;-)

Ciao,
Johannes

>
> One more thing: your patch is based on the main Git repo. That repo is
> not where git-gui development takes place. The current "official" repo
> for git-gui is over at [2]. Please base your patches on top of that
> repo.
>
> [0] https://matheustavares.gitlab.io/posts/first-steps-contributing-to-git#submitting-patches
> [1] https://gitgitgadget.github.io/
> [2] https://github.com/prati0100/git-gui
>
> Now on to the nitty gritty details.
>
> I like the idea. In fact, there were some discussions recently about
> having configurable key bindings for _all_ shortcuts in git-gui. Nothing
> concrete has been done in that direction yet though. But I feel like
> this is a pretty good first step.
>
> On 03/10/19 08:18PM, harish k wrote:
> > Hi All,
> > I', Just reopening this feature request.
> > A quick summary of my proposal is given below.
> >
> > 1. This PR will allow an additional configuration option
> > "guitool.<name>.gitgui-shortcut" which will allow us to specify
> > keyboard shortcut  for custom commands in git-gui
>
> A pretty nice way of doing it. But I would _really_ like it if there was
> an option in the "create tool" dialog to specify the shortcut. People of
> a gui tool shouldn't have to mess around with config files as much as
> possible.
>
> > 2. Even there exists a parameter called "guitool.<name>.shortcut"
> > which is used by git-cola, I suggest to keep this new additional
> > config parameter as an independent config parameter, which will not
> > interfere with git-cola in any way, because, both are different
> > applications and it may have different "built-in" shortcuts already
> > assigned. So, sharing shortcut scheme between two apps is not a good
> > idea.
>
> David has advocated inter-operability between git-gui and git-cola.
> While I personally don't know how many people actually use both the
> tools at the same time, it doesn't sound like a bad idea either.
>
> So, sharing shortcuts with git-cola would be nice. Of course, it would
> then mean that we would have to parse the config parameter before
> feeding them to `bind`. I don't suppose that should be something too
> complicated to do, but I admit I haven't looked too deeply into it.
>
> I'd like to hear what other people think about whether it is worth the
> effort to inter-operate with git-cola.
>
> > 3. New parameter will expect shortcut combinations specified in TCL/TK
> > 's format and we will not be doing any processing on it. Will keep it
> > simple.
>
> Are you sure that is a good idea? I think we should at least make sure
> we are not binding some illegal sequence, and if we are, we should warn
> the user about it. And a much more important case would be when a user
> over-writes a pre-existing shortcut for other commands like "commit",
> "reset", etc. In that case, the menu entires of those commands would
> still be labelled with the shortcut, but it won't actually work.
>
> Yes, your current implementation keeps things simple, but I think some
> light processing would be beneficial. And if we do decide to go the
> inter-operability with git-cola route, then processing would be needed
> anyway, and we can validate there.
>
> > ---
> >  Documentation/config/guitool.txt | 15 +++++++++++++++
> >  git-gui/lib/tools.tcl            | 15 ++++++++++++---
> >  2 files changed, 27 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/config/guitool.txt b/Documentation/config/guitool.txt
> > index 43fb9466ff..79dac23ca3 100644
> > --- a/Documentation/config/guitool.txt
> > +++ b/Documentation/config/guitool.txt
> > @@ -48,3 +48,18 @@ guitool.<name>.prompt::
> >   Specifies the general prompt string to display at the top of
> >   the dialog, before subsections for 'argPrompt' and 'revPrompt'.
> >   The default value includes the actual command.
> > +
> > +guitool.<name>.gitgui-shortcut
> > + Specifies a keyboard shortcut for the custom tool in the git-gui
> > + application. The value must be a valid string ( without "<" , ">" wrapper )
> > + understood by the TCL/TK 's bind command.See
> > https://www.tcl.tk/man/tcl8.4/TkCmd/bind.htm
> > + for more details about the supported values. Avoid creating shortcuts that
> > + conflict with existing built-in `git gui` shortcuts.
> > + Example:
> > + [guitool "Terminal"]
> > + cmd = gnome-terminal -e zsh
> > + noconsole = yes
> > + gitgui-shortcut = "Control-y"
> > + [guitool "Sync"]
> > + cmd = "git pull; git push"
> > + gitgui-shortcut = "Alt-s"
>
> The "Documentation/" subdirectory belongs to the Git project, and not to
> git-gui, so if you want to see this change, you'd have to submit a
> separate patch for it.
>
> As far as git-gui's documentation is concerned, unfortunately there is
> none yet. I have been meaning to start working towards it, but just
> haven't found the time or motivation to do it yet.
>
> > diff --git a/git-gui/lib/tools.tcl b/git-gui/lib/tools.tcl
>
> Like I mentioned before, please base your patches on the git-gui.git
> repo, and not git.git. So, this should read "a/lib/tools.tcl" instead of
> "a/git-gui/lib/tools.tcl".
>
> I haven't looked at the contents of the patch because I can't apply it,
> and I'd prefer to tinker around with it before commenting. So please
> re-send the patch in the proper format and we can discuss the
> implementation :).
>
> > index 413f1a1700..40db3f6395 100644
> > --- a/git-gui/lib/tools.tcl
> > +++ b/git-gui/lib/tools.tcl
> [snip]
>
> --
> Regards,
> Pratyush Yadav
>

  reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 11:38 Harish K
2016-03-31 16:41 ` David Aguilar
2016-04-01  6:32   ` harish k
2019-10-03 14:48     ` harish k
2019-10-03 21:44       ` Pratyush Yadav
2019-10-04  8:49         ` Johannes Schindelin [this message]
2019-10-04 12:01           ` Pratyush Yadav
2019-10-05 20:16             ` Harish Karumuthil
2019-10-05 21:01               ` Pratyush Yadav
2019-10-06  9:49                 ` Johannes Schindelin
2019-10-06 18:39                   ` Pratyush Yadav
2019-10-06 19:37                     ` Philip Oakley
2019-10-06 20:27                     ` Johannes Schindelin
2019-10-06 21:06                       ` Pratyush Yadav
2019-10-07  9:20                         ` GitGUIGadget, was " Johannes Schindelin
2019-10-07 10:43                           ` Birger Skogeng Pedersen
2019-10-07 19:16                             ` Alban Gruin
2019-11-19 22:09                         ` Making GitGitGadget's list -> PR comment mirroring bidirectional, " Johannes Schindelin
2019-11-20 14:22                           ` Pratyush Yadav
2019-10-06 22:40                       ` Philip Oakley
2019-10-07  6:22                   ` Harish Karumuthil
2019-10-07 10:01                     ` Johannes Schindelin
2019-10-08 19:31                       ` Harish Karumuthil
2019-10-09 20:42                         ` Johannes Schindelin
2019-10-13 20:09                         ` Pratyush Yadav
2019-10-07  6:13                 ` Harish Karumuthil
2019-10-13 19:17                   ` Pratyush Yadav
  -- strict thread matches above, loose matches on Subject: below --
2016-03-29 11:29 Harish K
2016-03-31 16:49 ` David Aguilar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1910041046000.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=harish2704@gmail.com \
    --cc=me@yadavpratyush.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git