Hi Harish, Sorry for the late reply. Couldn't find much time last few days. On 07/10/19 11:43AM, Harish Karumuthil wrote: > Hi Pratyush, Regarding your messages, > > >On Sun, 2019-10-06 at 02:31 +0530, Pratyush Yadav wrote: > > You don't need to "set up" an email client with git-send-email. > > git-send-email is an email client itself. Well, one which can only send > > emails. > > For now, I am sticking with a mail client ( evolution ) which does minimal > ( or atleast transparent ) preprocessing ( Tab => space conversion , line > wrapping etc ). > Now I can send patches using the output of `git diff --patch-with-stat` > command and I hope is it enough for now. > Personaly I dont' like any solution which requires storing our mail password > as a plain text file. I'm afraid this won't work. The '.patch' file that `git-format-patch` generates also contains your commit message and the author information. All those are needed to properly convert your patch to a commit in my repo. The output of `git diff --patch-with-stat` won't be enough. As for not wanting to store your mail password in a plain text file, check out [0]. And then there is GitGitGadget too, which I'd recommend since you seem to be having trouble sending patches directly :). > > You haven't sent '/submit' over there, so those emails aren't in the > > list (and my inbox) yet. You need to comment with '/submit' (without > > the quotes) to tell GitGitGadget to send your PR as email. > > I thought, lets finalize discussion about all the changes here in mail > thread it self before submitting the patch. Otherwise, That is why I didn't > submitted the patch. Makes sense. > > One point I forgot to mention earlier was that I'm honestly not a big > > fan of separating the binding and accelerator label. I understand that > > you might not have the time to do this, but I think it is still worth > > mentioning. Maybe I will implement something like that over your patch. > > But it would certainly be nice if you can figure it out :). > > I think there is a small missunderstanind in that point. > > I agree that, in the initial implementation ( which I did @ 2016 ) menu > labels were separated from binding keys. But in the last update, it is not > like that. > > Currently, user only need to specify single config value which is > `guitool.<name>.gitgui-shortcut` and don't have to specify accel-lable > separatly. > Label is generated from the shortcut. Thanks for clarifying. It indeed was a misunderstanding. > > Either ways, detecting an existing shortcut is pretty easy. The `bind` > > man page [1] says: > > > > If sequence is specified without a script, then the script currently > > bound to sequence is returned, or an empty string is returned if there > > is no binding for sequence. > > > > So you can use this to find out if there is a binding conflict, and warn > > the user. > > Will try this. Thanks! [0] https://www.softwaredeveloper.blog/git-credential-storage-libsecret -- Regards, Pratyush Yadav
