Holger Hellmuth <hellmuth@xxxxxxxxxx> writes: > On 13.03.2012 14:17, Junio C Hamano wrote: >> that is required to understand it is greater. Also the current >> implementation of 'upstream' has some weird semantics (or undesigned >> bugs) pointed out by Peff, which would make it even more confusing. > > If Peff's "push to same branch in a different remote" is a bug (and > IMHO it is) it should not count as a reason for what should be the > default. I may phrased it poorly, but I don't think you mean "if the bug is fixed, then the behaviour of upstream is simple and easy to understand". The very reason the bug exists in the first place is that the semantics that mode wants to give its users is complex enough that even the people who should know (i.e. those who implement it) overlooked that there is a corner case their implementation was not handling. It is a demonstration that upstream is not an easy-to-understand choice to throw at new people. > By the way, the documentation is very confusing in its description > what git push without parameters does. For example it is not really > explained in the description or options part, the only explanation is > in the Examples. There "git push" points to "git push origin" and: > ------------- > "git push origin > Without additional configuration, works like git push origin :. > > The default behavior of this command when no <refspec> is > given can be configured by setting the push option of the > remote. > ------------ > > Now the refspec documentation never says anything about what '.' means > (the only docu about refspecs I could find is in pull-fetch-param.txt That should read: ... works like "git push origin :". That dot you see after the colon is a full-stop for the sentence, not a part of any refspec. > Is this patchworthy (in that case I'll try to make one) or did I just > not read at the right places? It is patch-worthy; you already know that it made you waste time looking for ':.'---the documentation shouldn't have done that. -- 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