On Thursday 07 December 2006 00:23, Johannes Schindelin wrote: > Hi, > > On Wed, 6 Dec 2006, Josef Weidendorfer wrote: > > > On Wednesday 06 December 2006 13:07, Andy Parkins wrote: > > > The [branch "master"] section is such that there is no change to the > > > functionality of git-pull, but that functionality is now explicitly > > > documented. > > > > 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. IMHO there only should be one place/command which is creating new branches, and which is called by other porcelain commands [*1*]. This way, if we add some further action to "branching off" (like adding a default merge branch), we will not miss any place where a new branch will be created, thus keeping everything consistent. Why should we not setup branch.*.merge when a create a new development branch from a tracking branch via "git branch", or "git checkout -b" ? Josef [*1*] I recently made up my mind about this. I suggested a patch (see "[PATCH/RFC] Convenient support of remote branches in git-checkout" in the mail archive), which also set up "branch.*.merge" in a similar way as this patch is doing. And I got - rightly - the same response from Junio as I made myself in this case. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html