Re: Remove help advice text from git editors for interactive rebase and reword
Show 8 quoted lines
> On 24 Jul 2017, at 01:09 , Junio C Hamano <gitster@pobox.com> 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.
Kirill Likhodedov <kirill.likhodedov@jetbrains.com>