Re: Pitfalls in auto-fast-forwarding heads that are not checked out?

[Johannes Sixt <j6t@kdbg.org>]

Am 04.05.2013 00:46, schrieb Martin Langhoff:
> I am building a small git wrapper around puppet, and one of the
> actions it performs is auto-fastforwarding of branches without
> checking them out.
> 
> In simplified code... we ensure that we are on a head called master,
> and in some cases "ppg commit", will commit to master and...
> 
>   ## early on
>   # sanity-check we are on master
>   headname=$(git rev-parse --symbolic-full-name --revs-only HEAD)
>   if [ "$headname" -ne "refs/heads/headname" ]; then

You mean "refs/heads/master" and "!=" here because -ne is numeric
comparison in a shell script.

>       echo >&2 "ERROR: can only issue --immediate commit from the
> master branch!"
>       exit 1
>   fi
> 
>   ## then
>   git commit -bla blarg baz
> 
>   ## and then...
> 
>   # ensure we can ff
>   head_sha1=$(git rev-parse --revs-only master)
>   mb=$(git merge-base $production_sha1 refs/heads/master)
>   if [[ "$mb" -ne "$production_sha1" ]]; then

Your approach looks OK (but note again the incorrect "-ne").

Since git 1.8.0 you can express this check as

    if git merge-base --is-ancestor $production_sha1 refs/heads/master

>       echo >&2 "ERROR: cannot fast-forward master to production"

	echo >&2 "ERROR: cannot fast-forward production to master"

>       exit 1
>   fi
>   $GIT_EXEC_PATH/git-update-ref -m "ppg immediate commit"
> refs/heads/production $head_sha1 $production_sha1 || exit 1
> 
> Are there major pitfalls in this approach?

I don't think there are.

> I cannot think of any, but
> git has stayed away from updating my local tracking branches; so maybe
> there's a reason for that...

I don't understand what you are saying here. What is "that"?

-- Hannes