Re: git pull and merging.

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 8, 2006, 11:48 UTC
Message-ID: <elbj9g$og4$1@sea.gmane.org>
In-Reply-To: <200612071227.46194.Josef.Weidendorfer@gmx.de>

Josef Weidendorfer wrote:

Show 16 quoted lines

> Now looking at it, I think this semantic really is screwed and utterly confusing.
> Why decides branch.*.merge about actions done in fetch (I think even if you did
> "git fetch" alone)? OK, actually, that is an implementation detail and not
> really important.
> 
> More important: Because "branch.*.merge" specifies a _remote_ branch,
> the user has to understand that this info is already used in the fetch.
> The intuitive mental model of a user about how it works IMHO is that
> "branch.*.merge" is checked in the merge phase (as the name of the option suggests).
> But this way, how could the merge phase know about any remote branch at all,
> which does not need to be touched at all in the merge phase?
> 
> IMHO we should somehow change the semantic of branch.*.merge to specify the _local_
> refspec part, as this is the branch which actually gets merged.
> This is the only way that a user could grasp the meaning of it.
> Perhaps introduce "branch.*.defaultmerge", and obsoleting "branch.*.merge"?

The change of semantic would prohibit the "pull without tracking branch" semantic (probably not used anymore, since git supports multiple heads from long time).

I proposed in another thread to allow to either specify full refspec (in addition to current specifying remote branch), or ':' and local branch. Or perhaps add branch.*.localmerge configuration option?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git