Re: Remove help advice text from git editors for interactive rebase and reword

On Mon, Jul 24, 2017 at 01:26:09AM +0300, Kirill Likhodedov wrote:

quoted

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.

Yes, but if you are adding a config variable that is only ever meant to
be used from the command line, it probably makes sense to just add a
command-line option.

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.

That is exactly what advice.* is for, but it is about the _user_
deciding that they don't care about seeing that text. Not a tool that is
calling Git deciding that in one particular context, it would like to
suppress the hint text.

So I actually would be OK with having an advice.* option to squelch
rebase and/or commit instructions. But only if users decide they would
never like to see that text. So yes, your tool could piggy-back on that
config option, but it would be a slight abuse of the intent.

quoted

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.

If this is all scripted anyway, wouldn't it be an option to just process
the commit message in your program?  The format is well-known, with
hints and instructions on lines marked by core.commentChar ("#" by
default).

I'm not sure exactly of the flow in which the user sees the commit
message buffer (i.e., if you are invoking the editor yourself, or if you
are relying on git-commit to do so). But even in the latter case, you
can hook the editor invocation to do whatever you like. For example:

  GIT_EDITOR='f() { sed -i /^#/d "$1"; $EDITOR "$1"; }; f' git commit

That allows you not only to strip out the existing instructions, but to
insert whatever other instructions you choose.

-Peff