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

From: Petr Baudis <pasky@suse.cz>
Date: Sep 27, 2005, 10:17 UTC
Message-ID: <20050927101744.GD30889@pasky.or.cz>
In-Reply-To: <7vll1jh8zr.fsf@assigned-by-dhcp.cox.net>

Dear diary, on Mon, Sep 26, 2005 at 10:25:28PM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Show 14 quoted lines

> Petr Baudis <pasky@suse.cz> writes:
> 
> > ... Either way, git-pull won't be equivalent to git-fetch &&
> > git-merge (or git-resolve or whatever is the core porcelain
> > command) anymore.
> 
> "pull = fetch + merge" is a reasonable approximation to use when
> you explain what they are to somebody, but taking it literally
> would harm usefulness.
> 
> It is what you have already lived with for a while.  "git pull
> .../linux/2.6.git v2.6.11-tree v2.6.12" would fetch both heads
> but merges v2.6.12 head only (because v2.6.11-tree is not
> something you can merge with).

Yes, but that's a rather obscure case. :-) But well, your use cases convinced me that the behaviour to fetch multiple heads even if you are going to merge just one of them is useful enough. However, I still think that the user should be required to specify the to-be-merged head manually if the default choice isn't explicitly written in the remotes file.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.