Ramkumar Ramachandra <artag...@gmail.com> writes: > @@ -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? 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. And I already explained that to you at least twice. cf. http://article.gmane.org/gmane.comp.version-control.git/228399 But after writing it down this way, I realize that introduction of base_reflog_action (or GIT_REFLOG_NAME which is a moral equivalent) is not helping us at all. As long as calls to "git" command in the second category exists in these scripts, GIT_REFLOG_ACTION *must* be kept pristine after set_reflog_action sets it, so we can get rid of this new variable, and rewrite 3.a and 3.b like so: 3-a) GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: custom message" \ git cmd 3-b) SAVED=$GIT_REFLOG_ACTION GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: custom message" output git cmd GIT_REFLOG_ACTION=$SAVED or ( GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: custom message" output git cmd ) That essentially boils down to the very original suggestion I made before Ram introduced the base_reflog_action. -- 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
