Re: GIT 0.99.7d, and end of week status.

From: Junio C Hamano <junkio@cox.net>
Date: Sep 25, 2005, 23:46 UTC
Message-ID: <7v7jd4n22i.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <87psqwzs3x.fsf@ualberta.net>

Tom Prince <tom.prince@ualberta.net> writes:

Show 12 quoted lines

>> When you already have a repository to track git.git, I would
>> recommend to have something like this in .git/remote/origin:
>>
>>     URL: http://kernel.org/pub/scm/git/git.git
>>     Pull: master:origin maint:maint +pu:pu
>>
>
> A warning when you do this. If you say 
>
>   git pull origin
>
> then your master will be updated with an octopus merge of the three heads.

Ahhhhhhhh. That is true. I always do "git fetch" and never do "git pull" against anything but a local repository, heads explicitly specified. You are right. The defaulting behaviour is incredibly broken.

Do people agree it is a good idea to change the "git pull origin" to mean "fetch all the default refs specified on Pull: lines, and merge only the first one into the current branch"?

"git pull" without remote nor refspecs is a synonym to "git pull origin" as before, and 99.99% of the time "git pull" from a remote repo without explicit refspec is doing just one head merge, so I think this is a sane default, much saner than the current mess, while still allowing you to keep track of what's happening in the other branches by doing fetches of all the heads at once.

Opinions?