Junio C Hamano wrote:
>> @@ -59,6 +63,9 @@ else
>> return $?
>> fi
>>
>> + # 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.
> The original orig_reflog_action you borrowed this may have been an
> acceptable local solution inside
> git-rebase--interactive that does not call out to amyting, but
> the above comment a good demonstration that shows why this cannot be
> a good general solution that scales across scriptlets.
Nonsense. How do I set a custom reflog action when a certain flag is
passed to my script (like git-rebase.sh:333) without *overriding* an
existing GIT_REFLOG_ACTION? How do I construct cute start/pick/reword
prefixes elegantly (like in
git-rebase--interactive.sh:comment_for_reflog()) without *overriding*
an existing GIT_REFLOG_ACTION? In both these examples, I'm setting a
GIT_REFLOG_ACTION for the "rest of the code" to use. I don't care
about the exact command sequence, but I know that they respect
GIT_REFLOG_ACTION; so I'm setting one in advance.
When calling out to an external scriptlet, I want to define my own
reflog message: when I call out to "am" from "rebase -i", it should
write a "rebase -i: " message, and ignoring its own
set_reflog_message(). _That_ can be done using the subshell thing you
proposed. And I have absolutely no clue why
(
export GIT_REFLOG_ACTION
git am
)
is "more scalable" than
GIT_REFLOG_ACTION="$base_reflog_action"
git am
> And I already explained that to you at least twice.
You just gave set_reflog_action() and GIT_REFLOG_ACTION some sort of
God status, and proposed to make the scripts more ugly and less
extensible.
... 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
