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

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

 



On Sat, May 4, 2013 at 3:34 AM, Johannes Sixt <j6t@xxxxxxxx> 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...

>> 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@xxxxxxxxx
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
--
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]