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 >
