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:


            GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: custom message" \
                    git cmd


            GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: custom message"
            output git cmd


                    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

Reply via email to