On Thursday 07 December 2006 07:46, Aneesh Kumar K.V wrote:
quoted text
> Josef Weidendorfer wrote:

quoted text
> > Now, instead of "git pull", git should default to
> > 
> > 	git pull origin refs/heads/devel:refs/remotes/origin/devel
> 
> 
> 
> this means the remote reference is refs/heads/devel and local tracking
> branch for that is refs/remotes/origin/devel. 

Yes.

quoted text
> > ie. it should update the local tracking branch "refs/remotes/origin/devel"
> > with the remote branch "refs/heads/devel".
> > The tracking branch "refs/remotes/origin/devel" will be merged with current
> > branch afterwards.
> > 
> 
> 
> That will be merged is the tricky part.

No. The merging part actually is the easiest, because everything about
what to merge with what is already decided in "git pull" 's fetch phase:

* git fetch leaves the branches fetched _and_ what to merge of them
in .git/FETCH_HEAD. Example for "git pull" it git.git's master(shorted):

de51fa... branch 'master' of git://.../git/git
49ed2b... not-for-merge   branch 'maint' of git://.../git/git
b772ef... not-for-merge   branch 'next' of git://.../git/git

Which means: Already in the fetch phase, we look up branch.*.merge to
decide what to write into this file.

* the merge phase just looks up .git/FETCH_HEAD and merges all branches into
the current branch which are _not_ marked as "not-for-merge". There
is nothing tricky here: We did the 1st phase of pull in the same
"current" branch, so there really is no need to check any branch.*.merge
value again.

quoted text
> > Now looking at the documentation for branch.<name>.merge, it talks
> > about the remote branch, which is "refs/heads/devel" in your case, ie.
> > the first part of the refspec of the full "git pull" command above.
> > 
> 
> This is most confusing part. What merge indicate is not about refs/heads/devel
> should track refs/remotes/origin/devel. That is specfied in the remote config option.

Yes. But the value of branch.*.merge, which is the _remote_ side of such a refspec
tracking specification given in remote.*.fetch's, will be checked against all
remote parts of refspecs fetched in the 1st phase of "git pull". And it is already
decided in the fetch phase what to merge.

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"?

quoted text
> I guess we need to have a standard way of saying the branches. 
> 
> May be we want to document it in repo-config.
> 
> local branch on which changes can be made <branch-name>
> local tracking branch refs/remotes/<remote-name>/<branch-name>

This is not forced, but can be changed by configuration.

quoted text
> remote branch refs/heads/<branch-name>

?

Josef
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html