From: Junio C Hamano Date: Tue, 13 Mar 2012 22:54:26 GMT Subject: Re: [RFC PATCH] push: start warning upcoming default change for push.default Message-ID: <7v62e8t8m5.fsf@alter.siamese.dyndns.org> In-Reply-To: <20120313213045.GD27436@sigill.intra.peff.net> Jeff King writes: > The branch.*.pushRemote you mentioned would help with that. But for me, > I would much rather have simply push.defaultRemote. I would think that is a natural way to extend it. Don't we already have something similar that is per repository default that can be overriden with per branch configuration? > Speaking of which, I often get annoyed at the per-branch > auto-configuration of upstreams. For example, I find myself doing this: > > [get an idea, read a bug report on the list, etc] > $ cd git > $ hack hack hack > [oh, this is turning into something real. Let's make a branch] > $ git checkout -b jk/bug-fix > $ git commit -m 'fix bug' > > but now my bug-fix branch is based off of wherever I was (which is > usually some private topic-integration branch I run most of the time). What in "checkout -b jk/bug-fix" makes jk/bug-fix a downstream of origin/master? I admit my brain is not working very well today, but I would have expected the branch to have either your local private topic integration branch as its @{u}, or no @{u} defined for it at all. Perhaps there is a design error of some sort around that code? > Which makes me wonder if perhaps people are using "upstream" to mean > several different thing. I use it to say "this is the branch that this > topic is based off of", which makes "git log @{u}.." helpful, "git > rebase -i" just work, and gives some meaning to the ahead/behind message > (it shows how my topic relates to the main project). > > But I think people also use upstream to mean "this is the definitive > version of this branch in some central repo". So they would say that > "jk/bug-fix" is based on "origin/jk/bug-fix". And the ahead/behind > message is about "do I have any local work that needs pushed, or any > remote work that needs pulled?" I think that is the more common interpretation. Earlier you said ahead/behind gives "some meaning", but compared to this "how many more do I have, how many more do others have while I was looking the other way", I am not sure what kind of cue that "some meaning" would give us. > And I wonder if this is where some of the debate for > push.default=upstream comes from. Whether that is useful to you or not > would depend on how you set up your branches. In the latter model, I > would think pushing to the upstream would be the right thing. No question about the conclusion in the last sentence, but at the same time, I do not think the push.default is about making things work smoothly for people who configure everything right. >> Because "upstream" is meant to be "For the branch I am on, you know >> how the branches map between the remote repository, so you already >> know what the right thing to do---do it" mode, the correct "guess" >> in your case is to error out and say "Nah, you are not talking with >> your upstream, so I do not have any clue what branches you want to >> push out and how. As you said that the push.default is upstream, not >> matching, I refuse to even do the matching push in your case. This >> is an error. Be more specific". > > Yeah, I agree that is the only sane thing to do. Perhaps this can be a good sample entry for the experimental "tracker" thing to keep track of to see how the workflow will evolve around it; unless neither of us would get to work on it immediately, it is very likely to be forgotten, as this is a tangent in the overall discussion, even though the bug is real and solution is clear.