Jeff King <peff@xxxxxxxx> writes: > On Wed, Mar 28, 2012 at 12:47:12PM -0700, Junio C Hamano wrote: > >> * When you do not tell which branches and tags to push to the "git push" >> command in any way, the command used "matching refs" rule to update >> remote branches and tags with branches and tags with the same name you >> locally have. In future versions of Git, this will change to use the >> "upstream" rule to update the branch at the remote you would "pull" >> from into your current branch with your local current branch. The >> release after 1.7.10 will start issuing a warning about this change, >> to encourage you to tell the command what to push out, e.g. by setting >> push.default configuration. > > Did we decide that "upstream" will be the new rule in future versions? I > still have some misgivings about that (versus "current"), but I thought > the only decision we were settling now was whether to change at all. I counted the AOL me-too on "upstream" vs "current" ;-) Seriously speaking, I think we have enough time to make sure that "upstream" errors out with an appropriate advice when: - The user says "git push" (no remote, no refspec) on a branch without any tracking set; or - The user says "git push $remote" (either remote nick or url, no refspec) when there is no "remote.$remote.push" and the current branch does not have tracking set to that remote (includes the cases where it does not have any tracking set, and where it has tracking set to different remote). Once that happens, there no longer is a reason "current" is more suitable for beginners, I would think. The "easy to understand for beginners" explanation for "upstream" becomes: Nothing is pushed until you explicitly say what is pushed where, and you can say that by either: - setting remote.$remote.push; - setting branch.$current.merge; or - saying it on the command line. Compared to this, the "easy to understand for beginners" explanation for "current" which is "The current is pushed to the other end with the same name", may still be far easier to understand, but much less useful. -- 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