On Mon, Jul 24, 2017 at 01:26:09AM +0300, Kirill Likhodedov wrote:
> > 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.
> > 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
