On Friday 08 December 2006 23:34, Junio C Hamano wrote: > >> What convenience would it buy us (including but not limited to > >> new people), and if there is any, would that outweigh the > >> potential confusion factor to have two different configuration > >> variables that do exactly the same thing whose sole difference > >> is which side of the fetched branch namespace it uses to specify > >> the merge source? > > > > I just came up with a concrete patch. > > I am not saying that this is the only true solution. > > I admit that I do not use branch.*.merge and I do not know what > people find lacking in what Santi did in late September with > commit 5372806. What problem are we trying to solve (not a > rhetorical question -- I am truly lost here)? Is it only a > confusion between remote and local, or is there something that > cannot be expressed with the current scheme? More or less, yes. When this thread started, I remembered being bitten exactly by this issue. And I only understood my problem after looking and trying to understand the code. Therefore, it was quite easy to come up with this patch. IMHO, a problem really is the people do not want to read documentation. They see the branch.*.merge option in .git/config, and try to build their own mental model how it works. Perhaps the warning I added now would have been enough for me to see my error; it points at the misconfigured option. For sure, I would have looked up the manual for the meaning of this option after seeing the warning. But the previous documentation simply was way to short. Should I send a "simplified" patch? Josef - 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