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

[Petr Baudis <pasky@suse.cz>]

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...
> 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.