Jeff King <peff@xxxxxxxx> writes: > ... This is not a push.default issue, > but I think it is somewhat related, and maybe worth discussing along > with the topic of asymmetry. ... > I've mostly trained my fingers to type "git push > <my-publish-repo>", but I do occasionally forget. In an assymmetric set-up, you would typically push into one place but update from one or more places, so it might make sense to make it easier to say "git push" and "git pull $there". But that does not solve the fundamental issue, I would think. > Do other people with > asymmetric workflows find this annoying? Do they not care? Or are many > fewer people doing asymmetric things than I think? I think it is not "they do not care", but "they do not have a good solution". I do not think of anything offhand, either. > While I'm ranting, there's another weirdness I noticed. If I have > push.default set to upstream, and config like this: > > [branch "foo"] > remote = origin > merge = refs/heads/master > > then typing "git push" will go to foo's master branch. But if I type > "git push other-remote", then it will go to other-remote's master > branch. Which makes no sense to me. The upstream is foo's master, and > now we are making guesses about how the names on each side are the same. > Is this an intentional behavior? 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". > Actually, this is the thing that scares me the most about "upstream" as > a default, because in this case, you are implicitly performing the > equivalent of a fast-forward merge. So that's handy if you are a new > user who wants to publish your work back to the master branch. But that > has two problems: > > 1. If you are a new user who does like the implicit merge, you > may find it convenient not to have to learn about ... << and we > shouldn't discourage them from learning as it will be needed > anyway >> > > 2. If you are a new user who _doesn't_ want to do the merge, but > instead wants to publish your work-in-progress topic, then the > implicit merge-back-to-master behavior is wrong and dangerous. > << the newbie may push -f ruining the work of others >> I agree with both points. Also there is a cross-variant issue of the above two: If a new user hears "not fast-forward, first pull and then push again", that will be done on a topic branch, merging 'master' back and then pushing the result to 'master', leaving the 'master' of the user behind. > So far a lot of the discussion has focused on "what is the most sensible > default for the most number of people". But I wonder if a better > question is "what is the default that is the least likely to do > something dangerous and embarrassing". People who use git enough to say > "wow, I don't like this default for my workflow" are probably at the > point that they can configure push.default themselves. I do not think "the most number of people" is a high-priority issue, but "least damage" default may not be necessarily the best. Obviously, "nothing" is the least-damage option, and looking at how even people on this list cannot decide between current and upstream, I actually am very tempted to suggest it as the new default. -- 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