On 24 Jul 2017, at 01:09 , Junio C Hamano [off-list ref] 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.