On Thursday 07 December 2006 15:13, Johannes Schindelin wrote:
quoted text
> > > > Nice. However, changing "git-clone" for this is an adhoc solution and 
> > > > looks wrong.
> > > 
> > > Not to me. There is _no_ other place to put this, if you want to help 
> > > people graps the concept of branch.*.merge.
> > 
> > As far as I understand, git-clone defaults to kind of a mirror operation
> > while changing remotes ref names slightly as tracking branches, and
> > afterwards, it sets up a local branch for development, which is
> > branched off from the branch which tracks remote's master.
> 
> Yes. And I should back off from my strong language: I think this git-clone 
> the most obvious program to set branch.master.merge. It should make life 
> easier for new Git users.

Oh, no problem ;-) I myself used quite strong words. And I fully agree that
it makes life easier for users. And it is way easier to do it in git-clone
because
(1) in git-clone we _know_ that we branch of a tracking branch; in git-branch,
we first have to check if we want the configuration set.
(2) git-branch is more difficult to change because it's written in C :-)

However, as discussed in another thread, branch.*.merge currently has quite
a strange semantic [*1*], and without changing, users have no way to grasp this
configuration option.

And that branch renaming feature cooking in pu really has to move branch
attributes too, when we even officially set them now in git-clone.

Josef

[*1*] Currently, in branch.*.merge you have to specify the remote branch name
of a refspec which updates a local tracking branch in the fetch phase of git pull.
Ie. the option value has nothing todo with the merge action itself!
-
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