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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]