Junio C Hamano <gitster@xxxxxxxxx> writes: > Steffen Prohaska <prohaska@xxxxxx> writes: > ... >> I think 3) is the interesting case. "git push" should do >> nothing by default. > > NO WAY. > > Making things cumbersome to everybody does not achieve anything > useful except for a false sense of equality, does it? > > Drop that step (3). That is not useful to anybody. Thinking about it a bit more, I think my wording was a bit too strong and needs clarifying explanations. In a case like this, a fix of a "misfeature" for somebody is a regression for somebody else. Because there is no single right default that is appropriate for everybody. At least having _one_ default (and picking arbitrarily the historical default as that one default) is better than no default at all. The former will not inconvenience anybody by forcing what has been necessary from before. The latter will hurt the lucky ones whose preferred way happened to be the historical default. Keeping the status quo, however, will inconvinience unfortunate people whose preferred way was not the historical default. That's where we start to tackle the problem, by introducing the configuration variable. If we can come up with a way to tell projects that use the workflow better served with --current, perhaps when a remote is added to the repository (either the initial clone or "git remote add") and/or when a new branch is created. If we automatically set up the configuration "push.defaultRefs = current" in such a case, I suspect that we do not have to have the built-in default (at least, the value of the built-in default would not matter much). - 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
