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

Hi,

On Wed, 6 Dec 2006, Josef Weidendorfer wrote:

quoted

On Wednesday 06 December 2006 13:07, Andy Parkins wrote:

quoted

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