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

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: May 4, 2013, 11:35 UTC
Message-ID: <CACPiFCK=8KFX++Bg+LhymorSMnWgrj5Js+-f=UYyZnNY=n9WiA@mail.gmail.com>
In-Reply-To: <5184B9F9.2010708@kdbg.org>

On Sat, May 4, 2013 at 3:34 AM, Johannes Sixt <j6t@kdbg.org> wrote:

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

thanks! Yeah, I fixed those up late last night :-)

> Since git 1.8.0 you can express this check as
>
>     if git merge-base --is-ancestor $production_sha1 refs/heads/master

Ah, that's great! Unfortunate it's not there in earlier / more widely used releases of git.

>> Are there major pitfalls in this approach?
>
> I don't think there are.

Thanks...

Show 5 quoted lines

>> 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"?

When I do git pull, git is careful to only update the branch I have checked out (if appropriate). It leaves any other branches that track branches on the remote that has just been fetched untouched. I always thought that at some point git pull would learn to evaluate those branches and auto-merge them if the merge is a ff.

I would find that a natural bit of automation in git pull. Of course it would mean a change of semantics, existing scripts could be affected.

cheers,

m
--
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff