Re: confusion over the new branch and merge config

On Thu, Dec 21, 2006 at 03:01:21PM -0800, Junio C Hamano wrote:

> > $ git checkout -b local_next origin/next
> 
> "git checkout -b next origin/next" should work just fine, I
> think.
> 
> There was a talk about allowing "checkout -b <new> <track>" to
> add branch.<new>.merge and branch.<new>.remote if <track> can be
> proven to corresond uniquely to one remote and one branch from
> that remote; I think that would match the expectation most of
> the time but that "most" would not be 100% nor even 80%, so I
> think that should be an optional feature.  In any case, there
> was a talk but there is no code yet.

BTW, is there some explanation why branch.*.merge specifies a _remote_
head? The following would make much more sense to me:

[branch "master"]
remote = origin
merge = refs/remotes/origin/master

Because I don't _care_ that the other guy calls it refs/heads/master. I
care that I'm pulling from refs/remotes/origin/master on my end (and
however I get stuff into that branch is defined by the remote).

It also means that even without a remote, the merge option makes sense
(e.g., if I do repeated merges from one local branch to another). And it
means that it's _always_ correct for "checkout -b <new> <track>" to set
branch.<new>.merge to <track>, without having to worry about finding an
appropriate remote.

-Peff
-
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