Re: [PATCH v3 6/7] rebase: write better reflog messages

[Junio C Hamano <gitster@pobox.com>]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

>>> +     # always reset GIT_REFLOG_ACTION before calling any external
>>> +     # scripts; they have no idea about our base_reflog_action
>>> +     GIT_REFLOG_ACTION="$base_reflog_action"
>>>       git am $git_am_opt --rebasing --resolvemsg="$resolvemsg"
>>
>> Why does this reroll still use this base_reflog_action convention?
>
> Because it's simple and it makes sense.

Without $base_reflog_action hack, you have to make sure
GIT_REFLOG_ACTION is reasonably pristine when you call out other
people.  Even with $base_reflog_action, you still have to do the
same "keep GIT_REFLOG_ACTION pristine" like this one.  And in
addition, you have to maintain $base_reflog_action as if it is a
read-only variable [*1*].

So you are forcing people to maintain _two_ variables, instead of
just _one_, without making anything simpler.

What's so hard to understand why it is a wrong design?

> ... and we're discussing absolutely trivial inconsequential rubbish
> once again.  In any case, I've given up on arguing with you as it is
> clear that I can't possibly win.  Do whatever you want.

It is not about winning or losing.

If you truly think this is "inconsequential", that unfortunately
convinces me that you cannot yet be trusted enough to give you
latitude to design interfaces that span multiple programs X-<.


[Footnote]

*1* The original orig_reflog_action you borrowed from was bad enough
but it had an excuse that it was confined within the leaf level of
the callchain.  It was merely done as a way to stash the vanilla
action name (e.g. "rebase -i" before it is specialized into "rebase
-i pick" etc) away, so that it can easily "lose" the speciailzation
from GIT_REFLOG_ACTION while preparing for the next operation.