> On 24 Jul 2017, at 01:09 , Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Who is running "git commit --amend" and "git rebase -i" in the > workflow of a user of your tool? Is it the end user who types these > commands to the shell command prompt, or does your tool formulate > the command line and does an equivalent of system(3) to run it? > > I am assuming that the answer is the latter in my response. Yes, it is the latter case: the tool formulates the command line and forks a process. > Not at all interested, as that would mean your tool will tell its > users to set such a configuration variable and their interactive use > of Git outside your tool will behave differently from other people > who use vanilla Git, and they will complain to us. That's not true, since the tool can (and would) use the `git -c config.var=value rebase -i` syntax to set the configuration variable just for this particular command, without affecting the environment. Btw, if my proposal is so uninteresting, why the existing advice.* variables were previously introduced? I don't know the motivation, but assume that it was about making Git less wordy for experienced users. So I don't see any difference here. > But stepping back a bit, as you said in the parentheses, your tool > would need to grab these "hints" from Git, instead of having a > separate hardcoded hints that will go stale while the underlying Git > command improves, to be able to show them "separately". There is no need to call Git to get these "hints". They are quite obvious, well-known and can be hardcoded. However, I don't plan to use these hints anyway, since they are a bit foreign to the GUI of the tool I develop. For instance, for reword I'd like to show an editor containing just the plain commit message that the user is about to change.
<<attachment: smime.p7s>>
