Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Dec 7, 2006, 02:49 UTC
Message-ID: <200612070349.58521.Josef.Weidendorfer@gmx.de>
In-Reply-To: <Pine.LNX.4.63.0612070022180.28348@wbgn013.biozentrum.uni-wuerzburg.de>

On Thursday 07 December 2006 00:23, Johannes Schindelin wrote:

Show 14 quoted lines

> 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