Jeff King <peff@xxxxxxxx> writes: > On Sat, Dec 23, 2006 at 01:51:03AM -0800, Junio C Hamano wrote: > >> If you (or other people) use branch.*.merge, with its value set >> to remote name _and_ local name, and actually verify that either >> form works without confusion, please report back and I'll apply. > > This [using tracking branches in branch.*.merge] seems to be working for > me, but it is possible to get some confusing results with it. Try this > config: > > [remote "origin"] > url = /my/other/git/repo > fetch = refs/heads/master:refs/heads/origin > fetch = refs/heads/origin:refs/heads/junio > [branch "master"] > remote = origin > merge = refs/heads/origin > > That is, we have a local tracking branch 'X' which has the same name as > a remote branch 'X'. When we fetch, both will be marked for merge in > FETCH_HEAD, and git-pull will attempt to do an octopus. > > Is this too convoluted a config to worry about (no, I don't actually do > this in my repository -- I just constructed the most plausible reason I > could think of for having conflicting names). I actually think having a > branch.*.mergelocal would make just as much sense and would be more > robust (plus, it should be safe and sensible for "git-checkout -b foo > bar" to point branch.foo.mergelocal to refs/heads/bar). If we are to worry about, and I think we might have to, I think not worrying about mergelocal and not accepting the name of local tracking branch is the only sensible thing to do. Is there a problem if we did that? I do not think of any. - 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