{"thread":{"id":"30086","subject":"[ANNOUNCE] Git 1.7.10-rc3","startedAt":"2012-03-28T19:47:12Z","lastAt":"2013-02-01T01:15:13Z","messageCount":152,"participants":["Junio C Hamano","Jeff King","Nathan Gray","Seth Robertson","Matthieu Moy","demerphq","Dmitry Potapov","Jehan Bing","Michael Haggerty","Andrew Sayers","Felipe Contreras","Christopher Tiwald","Philip Oakley","Zbigniew Jędrzejewski-Szmek","Ævar Arnfjörð Bjarmason","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"187982","messageId":"7vd37wv77j.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":null,"subject":"[ANNOUNCE] Git 1.7.10-rc3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-28T19:47:12Z","receivedAt":"2012-03-28T19:47:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A release candidate Git 1.7.10-rc3 is now available for testing at\nthe usual places.\n\nNew translations and gitk updates are included in this update. Otherwise\nthings are calm.\n\n*B* *U* *T*\n\nThis one has the updates to the \"git merge\" that was discussed a few weeks\nago (cf. http://git-blame.blogspot.com/2012/02/anticipating-git-1710.html).\nYou can try this version to make sure you have enough time updating your\nscripts (and debug your updates to your scripts if needed) before the release\nhappens.\n\nThe release tarballs are found at:\n\n    http://code.google.com/p/git-core/downloads/list\n\nand their SHA-1 checksums are:\n\n9d940b9616dc37b06d76d500d59e2bf8c7c4ef8f  git-1.7.10.rc3.tar.gz\n810d7cdca63c9fa73fdbbfe1e6ab17bfa41b2c0b  git-htmldocs-1.7.10.rc3.tar.gz\n18962a2078d28d5955a04e79d838e3264d646539  git-manpages-1.7.10.rc3.tar.gz\n\nAlso the following public repositories all have a copy of the v1.7.10.rc3\ntag and the master branch that the tag points at:\n\n  url = git://repo.or.cz/alt-git.git\n  url = https://code.google.com/p/git-core/\n  url = git://git.sourceforge.jp/gitroot/git-core/git.git\n  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core\n  url = https://github.com/gitster/git\n\n--------------------------------\n\nGit v1.7.10 Release Notes (draft)\n=========================\n\nCompatibility Notes\n-------------------\n\n * From this release on, the \"git merge\" command in an interactive\n   session will start an editor when it automatically resolves the\n   merge for the user to explain the resulting commit, just like the\n   \"git commit\" command does when it wasn't given a commit message.\n\n   If you have a script that runs \"git merge\" and keeps its standard\n   input and output attached to the user's terminal, and if you do not\n   want the user to explain the resulting merge commits, you can\n   export GIT_MERGE_AUTOEDIT environment variable set to \"no\", like\n   this:\n\n\t#!/bin/sh\n\tGIT_MERGE_AUTOEDIT=no\n\texport GIT_MERGE_AUTOEDIT\n\n   to disable this behaviour (if you want your users to explain their\n   merge commits, you do not have to do anything).  Alternatively, you\n   can give the \"--no-edit\" option to individual invocations of the\n   \"git merge\" command if you know everybody who uses your script has\n   Git v1.7.8 or newer.\n\n * The \"--binary/-b\" options to \"git am\" have been a no-op for quite a\n   while and were deprecated in mid 2008 (v1.6.0).  When you give these\n   options to \"git am\", it will now warn and ask you not to use them.\n\n * When you do not tell which branches and tags to push to the \"git push\"\n   command in any way, the command used \"matching refs\" rule to update\n   remote branches and tags with branches and tags with the same name you\n   locally have.  In future versions of Git, this will change to use the\n   \"upstream\" rule to update the branch at the remote you would \"pull\"\n   from into your current branch with your local current branch.  The\n   release after 1.7.10 will start issuing a warning about this change,\n   to encourage you to tell the command what to push out, e.g. by setting\n   push.default configuration.\n\n\nUpdates since v1.7.9\n--------------------\n\nUI, Workflows & Features\n\n * various \"gitk\" updates.\n   - show the path to the top level directory in the window title\n   - update preference edit dialog\n   - display file list correctly when directories are given on command line\n   - make \"git-describe\" output in the log message into a clickable link\n   - avoid matching the UNIX timestamp part when searching all fields\n   - give preference to symbolic font names like sans & monospace\n   - allow comparing two commits using a mark\n   - \"gitk\" honors log.showroot configuration.\n\n * Teams for localizing the messages from the Porcelain layer of\n   commands are starting to form, thanks to Jiang Xin who volunteered\n   to be the localization coordinator.  Translated messages for\n   simplified Chinese and Swedish are available.\n\n * The configuration mechanism learned an \"include\" facility; an\n   assignment to the include.path pseudo-variable causes the named\n   file to be included in-place when Git looks up configuration\n   variables.\n\n * A content filter (clean/smudge) used to be just a way to make the\n   recorded contents \"more useful\", and allowed to fail; a filter can\n   now optionally be marked as \"required\".\n\n * Options whose names begin with \"--no-\" (e.g. the \"--no-verify\"\n   option of the \"git commit\" command) can be negated by omitting\n   \"no-\" from its name, e.g. \"git commit --verify\".\n\n * \"git am\" learned to pass \"-b\" option to underlying \"git mailinfo\", so\n   that a bracketed string other than \"PATCH\" at the beginning can be kept.\n\n * \"git clone\" learned \"--single-branch\" option to limit cloning to a\n   single branch (surprise!); tags that do not point into the history\n   of the branch are not fetched.\n\n * \"git clone\" learned to detach the HEAD in the resulting repository\n   when the user specifies a tag with \"--branch\" (e.g., \"--branch=v1.0\").\n   Clone also learned to print the usual \"detached HEAD\" advice in such\n   a case, similar to \"git checkout v1.0\".\n\n * When showing a patch while ignoring whitespace changes, the context\n   lines are taken from the postimage, in order to make it easier to\n   view the output.\n\n * \"git diff --stat\" learned to adjust the width of the output on\n   wider terminals, and give more columns to pathnames as needed.\n\n * \"diff-highlight\" filter (in contrib/) was updated to produce more\n   aesthetically pleasing output.\n\n * \"fsck\" learned \"--no-dangling\" option to omit dangling object\n   information.\n\n * \"git log -G\" and \"git log -S\" learned to pay attention to the \"-i\"\n   option.  With \"-i\", \"log -G\" ignores the case when finding patch\n   hunks that introduce or remove a string that matches the given\n   pattern.  Similarly with \"-i\", \"log -S\" ignores the case when\n   finding the commit the given block of text appears or disappears\n   from the file.\n\n * \"git merge\" in an interactive session learned to spawn the editor\n   by default to let the user edit the auto-generated merge message,\n   to encourage people to explain their merges better. Legacy scripts\n   can export GIT_MERGE_AUTOEDIT=no to retain the historical behavior.\n   Both \"git merge\" and \"git pull\" can be given --no-edit from the\n   command line to accept the auto-generated merge message.\n\n * The advice message given when the user didn't give enough clue on\n   what to merge to \"git pull\" and \"git merge\" has been updated to\n   be more concise and easier to understand.\n\n * \"git push\" learned the \"--prune\" option, similar to \"git fetch\".\n\n * The whole directory that houses a top-level superproject managed by\n   \"git submodule\" can be moved to another place.\n\n * \"git symbolic-ref\" learned the \"--short\" option to abbreviate the\n   refname it shows unambiguously.\n\n * \"git tag --list\" can be given \"--points-at <object>\" to limit its\n   output to those that point at the given object.\n\n * \"gitweb\" allows intermediate entries in the directory hierarchy\n   that leads to a project to be clicked, which in turn shows the\n   list of projects inside that directory.\n\n * \"gitweb\" learned to read various pieces of information for the\n   repositories lazily, instead of reading everything that could be\n   needed (including the ones that are not necessary for a specific\n   task).\n\n * Project search in \"gitweb\" shows the substring that matched in the\n   project name and description highlighted.\n\n * A new script \"diffall\" is added to contrib/; it drives an\n   external tool to perform a directory diff of two Git revisions\n   in one go, unlike \"difftool\" that compares one file at a time.\n\nForeign Interface\n\n * Improved handling of views, labels and branches in \"git-p4\" (in contrib).\n\n * \"git-p4\" (in contrib) suffered from unnecessary merge conflicts when\n   p4 expanded the embedded $RCS$-like keywords; it can be now told to\n   unexpand them.\n\n * Some \"git-svn\" updates.\n\n * \"vcs-svn\"/\"svn-fe\" learned to read dumps with svn-deltas and\n   support incremental imports.\n\n * \"git difftool/mergetool\" learned to drive DeltaWalker.\n\nPerformance\n\n * Unnecessary calls to parse_object() \"git upload-pack\" makes in\n   response to \"git fetch\", have been eliminated, to help performance\n   in repositories with excessive number of refs.\n\nInternal Implementation (please report possible regressions)\n\n * Recursive call chains in \"git index-pack\" to deal with long delta\n   chains have been flattened, to reduce the stack footprint.\n\n * Use of add_extra_ref() API is now gone, to make it possible to\n   cleanly restructure the overall refs API.\n\n * The command line parser of \"git pack-objects\" now uses parse-options\n   API.\n\n * The test suite supports the new \"test_pause\" helper function.\n\n * Parallel to the test suite, there is a beginning of performance\n   benchmarking framework.\n\n * t/Makefile is adjusted to prevent newer versions of GNU make from\n   running tests in seemingly random order.\n\n * The code to check if a path points at a file beyond a symbolic link\n   has been restructured to be thread-safe.\n\n * When pruning directories that has become empty during \"git prune\"\n   and \"git prune-packed\", call closedir() that iterates over a\n   directory before rmdir() it.\n\nAlso contains minor documentation updates and code clean-ups.\n\n\nFixes since v1.7.9\n------------------\n\nUnless otherwise noted, all the fixes since v1.7.9 in the maintenance\nreleases are contained in this release (see release notes to them for\ndetails).\n\n * Build with NO_PERL_MAKEMAKER was broken and Git::I18N did not work\n   with versions of Perl older than 5.8.3.\n   (merge 5eb660e ab/perl-i18n later to maint).\n\n * \"git tag -s\" honored \"gpg.program\" configuration variable since\n   1.7.9, but \"git tag -v\" and \"git verify-tag\" didn't.\n   (merge a2c2506 az/verify-tag-use-gpg-config later to maint).\n\n * \"configure\" script learned to take \"--with-sane-tool-path\" from the\n   command line to record SANE_TOOL_PATH (used to avoid broken platform\n   tools in /usr/bin) in config.mak.autogen.  This may be useful for\n   people on Solaris who have saner tools outside /usr/xpg[46]/bin.\n\n * zsh port of bash completion script needed another workaround.\n"},{"id":"188049","messageId":"20120329095236.GA11911@sigill.intra.peff.net","threadId":"30086","inReplyTo":"7vd37wv77j.fsf@alter.siamese.dyndns.org","subject":"Re: [ANNOUNCE] Git 1.7.10-rc3","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-29T09:52:36Z","receivedAt":"2012-03-29T09:52:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 28, 2012 at 12:47:12PM -0700, Junio C Hamano wrote:\n\n>  * When you do not tell which branches and tags to push to the \"git push\"\n>    command in any way, the command used \"matching refs\" rule to update\n>    remote branches and tags with branches and tags with the same name you\n>    locally have.  In future versions of Git, this will change to use the\n>    \"upstream\" rule to update the branch at the remote you would \"pull\"\n>    from into your current branch with your local current branch.  The\n>    release after 1.7.10 will start issuing a warning about this change,\n>    to encourage you to tell the command what to push out, e.g. by setting\n>    push.default configuration.\n\nDid we decide that \"upstream\" will be the new rule in future versions? I\nstill have some misgivings about that (versus \"current\"), but I thought\nthe only decision we were settling now was whether to change at all.\n\n-Peff\n"},{"id":"188098","messageId":"7vbonfqezs.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120329095236.GA11911@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git 1.7.10-rc3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-29T21:22:31Z","receivedAt":"2012-03-29T21:22:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Mar 28, 2012 at 12:47:12PM -0700, Junio C Hamano wrote:\n>\n>>  * When you do not tell which branches and tags to push to the \"git push\"\n>>    command in any way, the command used \"matching refs\" rule to update\n>>    remote branches and tags with branches and tags with the same name you\n>>    locally have.  In future versions of Git, this will change to use the\n>>    \"upstream\" rule to update the branch at the remote you would \"pull\"\n>>    from into your current branch with your local current branch.  The\n>>    release after 1.7.10 will start issuing a warning about this change,\n>>    to encourage you to tell the command what to push out, e.g. by setting\n>>    push.default configuration.\n>\n> Did we decide that \"upstream\" will be the new rule in future versions? I\n> still have some misgivings about that (versus \"current\"), but I thought\n> the only decision we were settling now was whether to change at all.\n\nI counted the AOL me-too on \"upstream\" vs \"current\" ;-)\n\nSeriously speaking, I think we have enough time to make sure that\n\"upstream\" errors out with an appropriate advice when:\n\n - The user says \"git push\" (no remote, no refspec) on a branch without\n   any tracking set; or\n\n - The user says \"git push $remote\" (either remote nick or url, no\n   refspec) when there is no \"remote.$remote.push\" and the current branch\n   does not have tracking set to that remote (includes the cases where it\n   does not have any tracking set, and where it has tracking set to\n   different remote).\n\nOnce that happens, there no longer is a reason \"current\" is more suitable\nfor beginners, I would think.\n\nThe \"easy to understand for beginners\" explanation for \"upstream\" becomes:\n\n  Nothing is pushed until you explicitly say what is pushed where, and you\n  can say that by either:\n\n   - setting remote.$remote.push;\n   - setting branch.$current.merge; or\n   - saying it on the command line.\n\nCompared to this, the \"easy to understand for beginners\" explanation for\n\"current\" which is \"The current is pushed to the other end with the same\nname\", may still be far easier to understand, but much less useful.\n"},{"id":"188102","messageId":"20120329221154.GA1413@sigill.intra.peff.net","threadId":"30086","inReplyTo":"7vbonfqezs.fsf@alter.siamese.dyndns.org","subject":"Re: [ANNOUNCE] Git 1.7.10-rc3","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-29T22:11:54Z","receivedAt":"2012-03-29T22:11:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 29, 2012 at 02:22:31PM -0700, Junio C Hamano wrote:\n\n> > Did we decide that \"upstream\" will be the new rule in future versions? I\n> > still have some misgivings about that (versus \"current\"), but I thought\n> > the only decision we were settling now was whether to change at all.\n> \n> I counted the AOL me-too on \"upstream\" vs \"current\" ;-)\n\nI did, too, but as you are so fond of reminding us, this is not a\ndemocracy. :)\n\n> Seriously speaking, I think we have enough time to make sure that\n> \"upstream\" errors out with an appropriate advice when:\n> \n>  - The user says \"git push\" (no remote, no refspec) on a branch without\n>    any tracking set; or\n> \n>  - The user says \"git push $remote\" (either remote nick or url, no\n>    refspec) when there is no \"remote.$remote.push\" and the current branch\n>    does not have tracking set to that remote (includes the cases where it\n>    does not have any tracking set, and where it has tracking set to\n>    different remote).\n\nRight. This was one of my two concerns: many upstream corner cases do not\ncurrently make sense, and before we switch to it as a default, those\nbugs need to be dealt with. And I think that refusing to push in those\ncases is the right thing.\n\nBut I would withhold a decision on \"upstream\" versus \"current\" until\nthose bugs are ironed out, because what people think of as \"upstream\"\n(today's current behavior)  may not be exactly what it ends up as.\nIn particular, the common beginner workflow of:\n\n  $ git clone ...\n  $ git checkout -b topic\n  $ hack hack hack\n  $ git push\n\nwould error out (whereas with \"current\", it would do something\nreasonably sane and predictable). The \"upstream\" push default relies on\nthe upstream config being set up in a sane way, but in my experience,\nthat does not always happen in every workflow.\n\n> The \"easy to understand for beginners\" explanation for \"upstream\" becomes:\n> \n>   Nothing is pushed until you explicitly say what is pushed where, and you\n>   can say that by either:\n> \n>    - setting remote.$remote.push;\n>    - setting branch.$current.merge; or\n>    - saying it on the command line.\n\nOr \"git has set up branch.$current.merge for you already\". The second of\nmy two concerns is that this:\n\n  $ git clone ...\n  $ git checkout -b topic origin/master\n  $ hack hack hack\n  $ git push\n\nwill try to implicitly fast-forward merge your commits onto master. Some\npeople have said they really like that behavior, but I think it can be a\nbit surprising for beginners.\n\nAnyway, I didn't exactly want to re-open the upstream versus current\ndebate at this point (and actually, I think a hybrid \"do nothing unless\nupstream and current would agree on the behavior, and give copious\nadvice\" approach might be the best thing). I just wanted to make sure\nthings were still open for consideration, and was concerned that we are\ncreating false expectations by putting \"upstream\" into the release\nnotes.\n\n-Peff\n"},{"id":"188113","messageId":"7vfwcqq2dw.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120329221154.GA1413@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git 1.7.10-rc3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-30T01:54:51Z","receivedAt":"2012-03-30T01:54:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> But I would withhold a decision on \"upstream\" versus \"current\" until\n> those bugs are ironed out, because what people think of as \"upstream\"\n> (today's current behavior) may not be exactly what it ends up as.\n> ...\n> Anyway, I didn't exactly want to re-open the upstream versus current\n> debate at this point ...\n\nActually I did want to ;-) An announcement \"We would be switching but we\ndon't know what to\" does not make sense.\n"},{"id":"188133","messageId":"20120330071358.GB30656@sigill.intra.peff.net","threadId":"30086","inReplyTo":"7vfwcqq2dw.fsf@alter.siamese.dyndns.org","subject":"push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-30T07:13:58Z","receivedAt":"2012-03-30T07:13:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 29, 2012 at 06:54:51PM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > But I would withhold a decision on \"upstream\" versus \"current\" until\n> > those bugs are ironed out, because what people think of as \"upstream\"\n> > (today's current behavior) may not be exactly what it ends up as.\n> > ...\n> > Anyway, I didn't exactly want to re-open the upstream versus current\n> > debate at this point ...\n> \n> Actually I did want to ;-) An announcement \"We would be switching but we\n> don't know what to\" does not make sense.\n\nOK. Then I think we shouldn't switch to upstream, and I'm ready to\ndebate it. :) I already posted my arguments earlier in the thread[1].\nWhat do you think?\n\nI think we can deal with my first issue (some workflows will cause \"git\npush\" to error out without doing anything) with targeted advice for each\nsituation.  But I still worry about the \"implied merge\" concern I\nraised, and I think the only way to fix that is to have a new mode that\nis almost but not quite \"upstream\" (like the upstream-current hybrid I\nmentioned).\n\nHas somebody volunteered to make the necessary fixes to \"push.default =\nupstream\" in the first place? At the very least we need the fixes you\nmentioned in your mail[2] before it can become the default. So maybe\ndoing those is a good first step (of course we are in release freeze,\nand it would be nice to settle this before v1.7.10 ships, so maybe there\nis not time).\n\n-Peff\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/194299\n\n[2] http://article.gmane.org/gmane.comp.version-control.git/194295\n"},{"id":"188199","messageId":"7vty15ltuo.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120330071358.GB30656@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-30T20:25:03Z","receivedAt":"2012-03-30T20:25:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"[dragging Matthieu, an advocate for \"upstream\", into this]\n\nJeff King <peff@peff.net> writes:\n\n> OK. Then I think we shouldn't switch to upstream, and I'm ready to\n> debate it. :) I already posted my arguments earlier in the thread[1].\n> What do you think?\n\nHonestly speaking, I do not care too deeply either way.  The difference\nbetween \"mixed\" and \"current/upstream\" is a very deep-rooted one and has\nmuch more to do with how \"batchy\" person you are, than if you are pushing\nto a shared or your own repository.\n\nThe underlying assumption for the original push semantics of \"mixed\" (or\nuse of remote.$there.push configuration) is that the way you work is to\nprepare all your branches to be pushed $there ready by the time when you\npush $there.  Concentrate perfecting your local work, perhaps even being\noblivious to what others do in the meantime, and then push out everything\nin one go.  The \"oblivious to what others do\" part is obviously harder to\narrange if you are pushing into a shared repository, but the connection\nbetween the \"shared repository workflow\" and \"push everything in one go\"\nis not fundamental.\n\nOn the other hand, both \"current/upstream\" are for people whose work habit\nis to complete _only_ the current branch; when you push it out $there, it\ndoes not matter if the other branches that will eventually be pushed out\nto the same repository are ready.\n\nAnd this \"only the doneness of the current branch matter\" is fundamentally\ndifferent from \"push everything in one go\", and I am already happy to see\nthat future Git is moving in this direction, which also matches the way\nvast majority of people seem to work.  So in that sense, I do not care\nwhich one we picked between \"current\" and \"upstream\".  Obviously the\nformer is much simpler to explain and understand, as people do not have to\nlearn upstream tracking before doing their first \"push\".\n\n> I think we can deal with my first issue (some workflows will cause \"git\n> push\" to error out without doing anything) with targeted advice for each\n> situation.\n\nYes.  I think that is up to the people who favored \"upstream\" over\n\"current\" to share their anecdotes to polish such advice messages.\n\n> But I still worry about the \"implied merge\" concern I\n> raised, and I think the only way to fix that is to have a new mode that\n> is almost but not quite \"upstream\" (like the upstream-current hybrid I\n> mentioned).\n\n... which is this.\n\n> my two concerns is that this:\n>\n>   $ git clone ...\n>   $ git checkout -b topic origin/master\n>   $ hack hack hack\n>   $ git push\n>\n> will try to implicitly fast-forward merge your commits onto master.\n\nAnd the reason why it is surprising to the beginners is?  Because \"topic\"\nand \"master\" (of \"origin/master\") are not the same name?\n\nIf you strip default features out of fear that it may be surprising to the\nbeginners, you would end up telling them to always explicitly say what\nthey want to push and to where, so we would need to draw a line somewhere.\nI tend to think that this is on the \"understandable\" side of the line\n(after all, I said \"Let's start a topic to be merged to origin/master\"\nwhen I started the topic, and I've been rebasing the topic up to date from\ntime to time), but obviously you don't think so.\n\nAnd I think your aversion to the \"implicit fast-forward\" will lead you to\nteach beginners to do this instead:\n\n   $ git clone ...\n   $ git checkout -b topic origin/master\n   $ hack hack hack\n   $ git checkout master\n   $ git merge topic\n   $ eyeball, test, think\n   $ git push\n\nwhich arguably is a more disciplined way, but I do not know if we can\nexpect that people can be trained to be _that_ well disciplined.\n\n> Has somebody volunteered to make the necessary fixes to \"push.default =\n> upstream\" in the first place? At the very least we need the fixes you\n> mentioned in your mail[2] before it can become the default. So maybe\n> doing those is a good first step (of course we are in release freeze,\n> and it would be nice to settle this before v1.7.10 ships, so maybe there\n> is not time).\n\nIf we were to take \"upstream\", as long as we commit to make it ready by\nthe time we switch, I do not see it as much of an issue.  Of course, the\n\"will change to 'upstream'\" message may need to be rephrased to say that\nthe idiotic usages that would trigger bugs in the current \"upstream\"\nimplementation I listed in the message you are referring to (which were\nactually taken from your earlier message, IIRC) are not supported and\ncurrently give undefined results, but will be fixed by the time we\nactually do the switch.\n\n> [1] http://article.gmane.org/gmane.comp.version-control.git/194299\n>\n> [2] http://article.gmane.org/gmane.comp.version-control.git/194295\n"},{"id":"188208","messageId":"20120330210112.GA20734@sigill.intra.peff.net","threadId":"30086","inReplyTo":"7vty15ltuo.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-30T21:01:12Z","receivedAt":"2012-03-30T21:01:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 30, 2012 at 01:25:03PM -0700, Junio C Hamano wrote:\n\n> And this \"only the doneness of the current branch matter\" is fundamentally\n> different from \"push everything in one go\", and I am already happy to see\n> that future Git is moving in this direction, which also matches the way\n> vast majority of people seem to work.  So in that sense, I do not care\n> which one we picked between \"current\" and \"upstream\".  Obviously the\n> former is much simpler to explain and understand, as people do not have to\n> learn upstream tracking before doing their first \"push\".\n\nRight. I also think either is a huge improvement for new users over\n\"matching\". But since we are going through the pain of changing the\ndefault, I think it's worth nit-picking between the options to come up\nwith the best default.\n\n> > I think we can deal with my first issue (some workflows will cause \"git\n> > push\" to error out without doing anything) with targeted advice for each\n> > situation.\n> \n> Yes.  I think that is up to the people who favored \"upstream\" over\n> \"current\" to share their anecdotes to polish such advice messages.\n\nI guess part of me is just cynical. We are announcing \"the default will\nchange to upstream\" under the assumption that upstream will get polished\nto everyone's liking. But until that polishing is actually done, I am\npessimistic. :)\n\n> > my two concerns is that this:\n> >\n> >   $ git clone ...\n> >   $ git checkout -b topic origin/master\n> >   $ hack hack hack\n> >   $ git push\n> >\n> > will try to implicitly fast-forward merge your commits onto master.\n> \n> And the reason why it is surprising to the beginners is?  Because \"topic\"\n> and \"master\" (of \"origin/master\") are not the same name?\n\nSort of. It is more because \"upstream\" is an overloaded concept. Perhaps\nyou created the branch from origin/master because you wanted to say\n\"this is where my topic is based, and when I 'rebase -i' later, I want\nit to be considered the baseline\". Or perhaps you meant to say \"I am\ngoing to work on origin's master branch, but I would prefer to call it\n'topic' here\".\n\nIn the latter case, pushing back to origin/master makes sense. They are\nforks of the same branch to you, and pushing back is how\nyou will share your changes to master. But in the former case, you may\nor may not consider them the same branch, and you may be pushing simply\nto share your work-in-progress of the topic. Putting that work onto\n\"master\" would be confusing in that case.\n\nNote that \"current\" has the same assumption in reverse. If you create a\nlocal \"master\" branch (whether or not it is based on a remote\n\"origin/master\"), you may or may not mean them to be the same branch.\n\nSo we have to decide when two things are forks of \"the same branch\", and\nwhen it is merely \"X is based on Y\", or \"X happens to have the same name\nas Y\". And I think the \"name is the same\" semantics are way more\nobvious.\n\nDo you recall discussions a few years back about git's branching model\nversus that of mercurial and other systems? One of the confusing things\nfor people new to git was the idea that git fundamentally doesn't care\nabout \"what is a branch\". They got confused that \"master\" in the local\nrepository really had no connection to \"master\" on the remote repository\n(whereas in hg, I think there is some magic in the DAG that connects\nthem). But that leads me to think that people really do consider \"same\nname is the same branch\", which means \"current\" is going to be a lot\nless likely to confuse people (for that matter, look at the current\nmatching semantics, which use name mapping; people get confused that we\nare pushing all matching branches, but I don't remember anyone ever\ncomplaining that they expect \"foo\" to go to \"bar\").\n\n> I tend to think that this is on the \"understandable\" side of the line\n> (after all, I said \"Let's start a topic to be merged to origin/master\"\n> when I started the topic, and I've been rebasing the topic up to date from\n> time to time), but obviously you don't think so.\n\nIs that what you said? Or did you say \"I am starting a new topic that\nwill be based on origin/master?\" I feel like the concept of \"upstream\"\nis very loosely specified, and can mean many things. And even if you do\neventually expect it to be merged into master, it does not mean you\nexpect it to do so by default during \"git push\". You might also simply\nwant to push the current state of your topic.\n\n> And I think your aversion to the \"implicit fast-forward\" will lead you to\n> teach beginners to do this instead:\n> \n>    $ git clone ...\n>    $ git checkout -b topic origin/master\n>    $ hack hack hack\n>    $ git checkout master\n>    $ git merge topic\n>    $ eyeball, test, think\n>    $ git push\n> \n> which arguably is a more disciplined way, but I do not know if we can\n> expect that people can be trained to be _that_ well disciplined.\n\nSure, I think that is a better workflow. But I don't expect everyone to\nfollow it, and I don't think \"upstream\" is wrong to behave the other\nway. You could also teach them what \"upstream\" means, and have them set\npush.default to it.\n\nUltimately, it is not about whether one workflow is better than the\nother. It is about having a default that stops the user and says \"hey, I\ndon't know what workflow you're using. So you need to tell me before I\ncan continue.\"\n\n-Peff\n"},{"id":"188209","messageId":"7vzkaxkccg.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120330210112.GA20734@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-30T21:28:31Z","receivedAt":"2012-03-30T21:28:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Mar 30, 2012 at 01:25:03PM -0700, Junio C Hamano wrote:\n>\n>> And the reason why it is surprising to the beginners is?  Because \"topic\"\n>> and \"master\" (of \"origin/master\") are not the same name?\n>\n> Sort of. It is more because \"upstream\" is an overloaded concept. Perhaps\n> you created the branch from origin/master because you wanted to say\n> \"this is where my topic is based, and when I 'rebase -i' later, I want\n> it to be considered the baseline\". Or perhaps you meant to say \"I am\n> going to work on origin's master branch, but I would prefer to call it\n> 'topic' here\".\n\nIn either case, you seem to be assuming (and it is a correct assumption,\neven though we may not use such a workflow) that the resulting branch, if\nlong lived, will be rebasing on top of origin/master.  And the reason why\nyou do that is because...\n\nBecause you would eventually want to get it integrated into origin's\nmaster.  Otherwise you can stay apart from origin/master and keep your\nfoundation solidly anchored to where you started.\n\nSo in that sense, in both cases, pushing back to origin/master is likely\nto be what the user expected in the first place.\n\nLike it or not, many parts of Git that is \"upstream\"-aware have been over\ntime taught to make it easier for the eventual result easier to be pushed\nback to the \"upstream\" at the remote, I think.  \"log --left-right @{u}...\"\nwill show what you and others have done, \"rebase\" knows to use @{u} when\nfiguring out on which commit to rebuild your current branch, etc.\n\n> So we have to decide when two things are forks of \"the same branch\", and\n> when it is merely \"X is based on Y\", or \"X happens to have the same name\n> as Y\". And I think the \"name is the same\" semantics are way more\n> obvious.\n\nI obviously agree with that.\n\n>> I tend to think that this is on the \"understandable\" side of the line\n>> (after all, I said \"Let's start a topic to be merged to origin/master\"\n>> when I started the topic, and I've been rebasing the topic up to date from\n>> time to time), but obviously you don't think so.\n>\n> Is that what you said? Or did you say \"I am starting a new topic that\n> will be based on origin/master?\"\n\nSee above ;-)  Having said that...\n\n> I feel like the concept of \"upstream\"\n> is very loosely specified, and can mean many things.\n\n...I tend to agree with it.  But I am not sure if that leads to \"we should\ndefault to 'current' because 'upstream' is too messy and blurry\".  At\nleast, not yet.\n\n> Ultimately, it is not about whether one workflow is better than the\n> other. It is about having a default that stops the user and says \"hey, I\n> don't know what workflow you're using. So you need to tell me before I\n> can continue.\"\n\nOK.  Obviously we would not want to default to 'push.default = nothing',\nand 'current' is far simpler to explain.\n\nBut then I am afraid that you may be inviting teachers to blindly teach\nbeginners to first set push.default to upstream, just like they do today\nwhere the default is matching, as most of them do know that upstream works\nfairly well with the way how _they_ work, without having an understanding\nthese gotchas in upstream you are (validly) raising as possible issues\nhere.  So in the end, we would have to clarify whatever 'upstream' does\nanyway, no?\n"},{"id":"188213","messageId":"20120330215344.GD20734@sigill.intra.peff.net","threadId":"30086","inReplyTo":"7vzkaxkccg.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-30T21:53:44Z","receivedAt":"2012-03-30T21:53:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 30, 2012 at 02:28:31PM -0700, Junio C Hamano wrote:\n\n> In either case, you seem to be assuming (and it is a correct assumption,\n> even though we may not use such a workflow) that the resulting branch, if\n> long lived, will be rebasing on top of origin/master.  And the reason why\n> you do that is because...\n> \n> Because you would eventually want to get it integrated into origin's\n> master.  Otherwise you can stay apart from origin/master and keep your\n> foundation solidly anchored to where you started.\n> \n> So in that sense, in both cases, pushing back to origin/master is likely\n> to be what the user expected in the first place.\n\nOK, I can agree with that (although I can come up with some corner\ncases, like a long-running branch that gets updates from master but is\nnever intended to be merged back in, I think we can safely say those are\nadvanced issues and not likely to be a problem for new git users).\n\nSo let's assume that you eventually plan for \"topic\" to go back into\n\"master\", and focus on a more concrete issue: _when_ to merge. You fork\na topic branch from origin/master and make some commits. You then run\n\"git push\". Did you mean:\n\n  1. I am ready for this work to go back to origin/master.\n\n  2. I am ready to publish my topic branch for others to review.\n\nI think it's ambiguous. And getting it wrong is potentially hard to\nretract (because you've published commits to what is probably supposed\nto be a stable, non-rewinding branch).\n\n> > I feel like the concept of \"upstream\"\n> > is very loosely specified, and can mean many things.\n> \n> ...I tend to agree with it.  But I am not sure if that leads to \"we should\n> default to 'current' because 'upstream' is too messy and blurry\".  At\n> least, not yet.\n\nI tend to think \"upstream\" is hopelessly blurry, and must remain so\nbecause there are too many similar concepts. That is, to fix it, you\nwould need to split it into several sub-concepts.\n\nFor example, I generally base all of my git.git topics on origin/master\n(where \"origin\" is your repo). But when I push them, they go to my\npublishing point. So there are two things I am interested in asking\nabout:\n\n  1. Where is my work compared to master? This is useful for enumerating\n     which commits are part of my topic, and for rebasing on top of\n     master.\n\n  2. What do my local branches have compared to their published\n     versions?  This is useful for knowing that I have work to be\n     published, or for realizing that I published work from another\n     machine that does not exist on the current machine.\n\nThose are two very different notions of upstream, and I want to use them\nwith different commands. I set @{u} to origin/master to handle (1). And\nI do (2) by matching names. But I would never want git-push to look at\n@{u}, because it is a totally different concept. Pushing is always about\n(2) for me.\n\nYes, this is a more complex workflow than many beginning git users will\nhave. But I think it is at the heart of the upstream confusion: just\nbecause you are based on some branch, and just because you ultimately\nwant to merge with it, does not mean that it is a good push destination.\n_Sometimes_ it is, and that is why the \"upstream\" push.default exists.\n\n> But then I am afraid that you may be inviting teachers to blindly teach\n> beginners to first set push.default to upstream, just like they do today\n> where the default is matching, as most of them do know that upstream works\n> fairly well with the way how _they_ work, without having an understanding\n> these gotchas in upstream you are (validly) raising as possible issues\n> here.  So in the end, we would have to clarify whatever 'upstream' does\n> anyway, no?\n\nYes, and we should make upstream better, no matter what the default is.\nBut I hoped that it would not be \"blindly teach\" but rather \"teach what\nupstream is\". Perhaps that is naive. But I feel like at least we will\nhave done the best we can by giving the user an opportunity to read the\ndocumentation or have somebody instruct them before setting \"upstream\",\nand not simply shipping it out of the box.\n\n-Peff\n"},{"id":"188215","messageId":"7vvcllka61.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120330215344.GD20734@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-30T22:15:34Z","receivedAt":"2012-03-30T22:15:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"In the meantime, we can do this.\n\n Documentation/RelNotes/1.7.10.txt |    9 +++------\n 1 file changed, 3 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/RelNotes/1.7.10.txt b/Documentation/RelNotes/1.7.10.txt\nindex d326ff8..6dcaf45 100644\n--- a/Documentation/RelNotes/1.7.10.txt\n+++ b/Documentation/RelNotes/1.7.10.txt\n@@ -32,12 +32,9 @@ Compatibility Notes\n  * When you do not tell which branches and tags to push to the \"git push\"\n    command in any way, the command used \"matching refs\" rule to update\n    remote branches and tags with branches and tags with the same name you\n-   locally have.  In future versions of Git, this will change to use the\n-   \"upstream\" rule to update the branch at the remote you would \"pull\"\n-   from into your current branch with your local current branch.  The\n-   release after 1.7.10 will start issuing a warning about this change,\n-   to encourage you to tell the command what to push out, e.g. by setting\n-   push.default configuration.\n+   locally have.  In future versions of Git, this will change to and push\n+   out only your current branch according to either \"upstream\" or \"current\"\n+   rule (we haven't yet decided which).\n \n \n Updates since v1.7.9\n"},{"id":"188216","messageId":"20120330222044.GA22371@sigill.intra.peff.net","threadId":"30086","inReplyTo":"7vvcllka61.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-30T22:20:44Z","receivedAt":"2012-03-30T22:20:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 30, 2012 at 03:15:34PM -0700, Junio C Hamano wrote:\n\n> In the meantime, we can do this.\n\nI'm OK with this. We could perhaps even invite people to take part in\nthe discussion. I'm not sure if that will generate anything more than a\nset of \"me too\" votes, though.\n\n> -   locally have.  In future versions of Git, this will change to use the\n> -   \"upstream\" rule to update the branch at the remote you would \"pull\"\n> -   from into your current branch with your local current branch.  The\n> -   release after 1.7.10 will start issuing a warning about this change,\n> -   to encourage you to tell the command what to push out, e.g. by setting\n> -   push.default configuration.\n> +   locally have.  In future versions of Git, this will change to and push\n> +   out only your current branch according to either \"upstream\" or \"current\"\n> +   rule (we haven't yet decided which).\n\ns/to and/to/\n\n-Peff\n"},{"id":"188221","messageId":"7vlimhk7rz.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120330071358.GB30656@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-30T23:07:12Z","receivedAt":"2012-03-30T23:07:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Has somebody volunteered to make the necessary fixes to \"push.default =\n> upstream\" in the first place? At the very least we need the fixes you\n> mentioned in your mail[2] before it can become the default.\n> ...\n> [2] http://article.gmane.org/gmane.comp.version-control.git/194295\n\nThere were two issues I raised in that message.  It turns out that we\nalready have the code for the first one.  The second one should look\nsomething like this:\n\n-- >8 --\nSubject: push: detect nonsense \"upstream\" check more carefully\n\nThe user can say \"git push\" without specifying any refspec.  When using\n\"upstream\" semantics via the push.default configuration, the user wants to\nupdate the \"upstream\" branch, which is the branch at a remote repository\nthe current branch is set to integrate with, with this command.\n\nThere are cases that \"git push\" do not make sense when push.default is set\nto \"upstream\":\n\n - The current branch does not have branch.$name.remote configured.  By\n   definition, \"git push\" that does not name where to push to will not\n   know where to push to.  The user may explicitly say \"git push $there\",\n   but again, by definition, no branch at repository $there is set to\n   integrate with the current branch in this case and we wouldn't know\n   which remote branch to update.\n\n - The current branch does have branch.$name.remote configured, but it\n   does not specify branch.$name.merge that names what branch at the\n   remote this branch integrates with. \"git push\" knows where to push in\n   this case (or the user may explicitly say \"git push $remote\" to tell us\n   where to push), but we do not know which remote branch to update.\n\n - The current branch does have both branch.$name.remote and\n   branch.$name.merge configured, but the user said \"git push $there\",\n   where $there does not match what \"branch.$name.remote\" is configured\n   to.  By definition, no branch at repository $there is set to integrate\n   with the current branch in this case and we wouldn't know which remote\n   branch to update.\n\nThe first two cases were already checked correctly, but the third case was\nnot checked and we ended up updating the branch named branch.$name.merge\nat repository $there, which was totally bogus.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n builtin/push.c |   32 ++++++++++++++++++++++++--------\n 1 file changed, 24 insertions(+), 8 deletions(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex d315475..3e18cd3 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -65,6 +65,16 @@ static void set_refspecs(const char **refs, int nr)\n \t}\n }\n \n+static int push_url_of_remote(struct remote *remote, const char ***url_p)\n+{\n+\tif (remote->pushurl_nr) {\n+\t\t*url_p = remote->pushurl;\n+\t\treturn remote->pushurl_nr;\n+\t}\n+\t*url_p = remote->url;\n+\treturn remote->url_nr;\n+}\n+\n static void setup_push_upstream(struct remote *remote)\n {\n \tstruct strbuf refspec = STRBUF_INIT;\n@@ -76,7 +86,7 @@ static void setup_push_upstream(struct remote *remote)\n \t\t    \"\\n\"\n \t\t    \"    git push %s HEAD:<name-of-remote-branch>\\n\"),\n \t\t    remote->name);\n-\tif (!branch->merge_nr || !branch->merge)\n+\tif (!branch->merge_nr || !branch->merge || !branch->remote_name)\n \t\tdie(_(\"The current branch %s has no upstream branch.\\n\"\n \t\t    \"To push the current branch and set the remote as upstream, use\\n\"\n \t\t    \"\\n\"\n@@ -87,6 +97,18 @@ static void setup_push_upstream(struct remote *remote)\n \tif (branch->merge_nr != 1)\n \t\tdie(_(\"The current branch %s has multiple upstream branches, \"\n \t\t    \"refusing to push.\"), branch->name);\n+\tif (strcmp(branch->remote_name, remote->name)) {\n+\t\tstruct remote *branch_dest = remote_get(branch->remote_name);\n+\t\tconst char **branch_dest_url, **dest_url;\n+\n+\t\tif (!push_url_of_remote(remote, &dest_url) ||\n+\t\t    !push_url_of_remote(branch_dest, &branch_dest_url) ||\n+\t\t    strcmp(dest_url[0], branch_dest_url[0]))\n+\t\t\tdie(_(\"You are pushing to remote '%s', which is not the \"\n+\t\t\t      \"upstream of your\\ncurrent branch '%s'.\\n\"),\n+\t\t\t    remote->name, branch->name);\n+\t}\n+\n \tstrbuf_addf(&refspec, \"%s:%s\", branch->name, branch->merge[0]->src);\n \tadd_refspec(refspec.buf);\n }\n@@ -196,13 +218,7 @@ static int do_push(const char *repo, int flags)\n \t\t\tsetup_default_push_refspecs(remote);\n \t}\n \terrs = 0;\n-\tif (remote->pushurl_nr) {\n-\t\turl = remote->pushurl;\n-\t\turl_nr = remote->pushurl_nr;\n-\t} else {\n-\t\turl = remote->url;\n-\t\turl_nr = remote->url_nr;\n-\t}\n+\turl_nr = push_url_of_remote(remote, &url);\n \tif (url_nr) {\n \t\tfor (i = 0; i < url_nr; i++) {\n \t\t\tstruct transport *transport =\n"},{"id":"188223","messageId":"7vhax5k7jl.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120330222044.GA22371@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-30T23:12:14Z","receivedAt":"2012-03-30T23:12:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Mar 30, 2012 at 03:15:34PM -0700, Junio C Hamano wrote:\n>\n>> In the meantime, we can do this.\n>\n> I'm OK with this. We could perhaps even invite people to take part in\n> the discussion. I'm not sure if that will generate anything more than a\n> set of \"me too\" votes, though.\n\nYeah, but at that point, people who pushed against \"matching\" will help\nus, instead of letting us hang dry.\n\nI really hated that 1.6.0 transition, where noisy vocal ones disappeared\nonce they got what they wanted without defending the choice they forced on\nus.\n\n Documentation/RelNotes/1.7.10.txt |   12 ++++++------\n 1 file changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/RelNotes/1.7.10.txt b/Documentation/RelNotes/1.7.10.txt\nindex d326ff8..5d72446 100644\n--- a/Documentation/RelNotes/1.7.10.txt\n+++ b/Documentation/RelNotes/1.7.10.txt\n@@ -32,12 +32,12 @@ Compatibility Notes\n  * When you do not tell which branches and tags to push to the \"git push\"\n    command in any way, the command used \"matching refs\" rule to update\n    remote branches and tags with branches and tags with the same name you\n-   locally have.  In future versions of Git, this will change to use the\n-   \"upstream\" rule to update the branch at the remote you would \"pull\"\n-   from into your current branch with your local current branch.  The\n-   release after 1.7.10 will start issuing a warning about this change,\n-   to encourage you to tell the command what to push out, e.g. by setting\n-   push.default configuration.\n+   locally have.  In future versions of Git, this will change to push out\n+   only your current branch according to either the \"upstream\" or the\n+   \"current\" rule.  Although \"upstream\" may be more powerful once the\n+   user understands Git better, the semantics \"current\" gives is\n+   simpler and easier to understand for beginners and may be a safer\n+   and better default option, but we haven't decided yet.\n \n \n Updates since v1.7.9\n"},{"id":"188269","messageId":"CA+7g9JxK5DHj3vbdGgF2dEJxvn=_ZfjAv7Y+AL_P-aO1FVB6-w@mail.gmail.com","threadId":"30086","inReplyTo":"20120330210112.GA20734@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Nathan Gray","fromEmail":"n8gray@n8gray.org","sentAt":"2012-03-31T22:49:09Z","receivedAt":"2012-03-31T22:49:09Z","isPatch":false,"sender":{"key":"n8gray@n8gray.org","avatar":"https://avatars.githubusercontent.com/u/82794?v=4"},"body":"On Fri, Mar 30, 2012 at 2:01 PM, Jeff King <peff@peff.net> wrote:\n> On Fri, Mar 30, 2012 at 01:25:03PM -0700, Junio C Hamano wrote:\n>> > my two concerns is that this:\n>> >\n>> >   $ git clone ...\n>> >   $ git checkout -b topic origin/master\n>> >   $ hack hack hack\n>> >   $ git push\n>> >\n>> > will try to implicitly fast-forward merge your commits onto master.\n>>\n>> And the reason why it is surprising to the beginners is?  Because \"topic\"\n>> and \"master\" (of \"origin/master\") are not the same name?\n>\n> Sort of. It is more because \"upstream\" is an overloaded concept. Perhaps\n> you created the branch from origin/master because you wanted to say\n> \"this is where my topic is based, and when I 'rebase -i' later, I want\n> it to be considered the baseline\". Or perhaps you meant to say \"I am\n> going to work on origin's master branch, but I would prefer to call it\n> 'topic' here\".\n>\n> In the latter case, pushing back to origin/master makes sense. They are\n> forks of the same branch to you, and pushing back is how\n> you will share your changes to master. But in the former case, you may\n> or may not consider them the same branch, and you may be pushing simply\n> to share your work-in-progress of the topic. Putting that work onto\n> \"master\" would be confusing in that case.\n>\n> Note that \"current\" has the same assumption in reverse. If you create a\n> local \"master\" branch (whether or not it is based on a remote\n> \"origin/master\"), you may or may not mean them to be the same branch.\n>\n> So we have to decide when two things are forks of \"the same branch\", and\n> when it is merely \"X is based on Y\", or \"X happens to have the same name\n> as Y\". And I think the \"name is the same\" semantics are way more\n> obvious.\n\nI'd like to offer my strong agreement as somebody who has just led his\nteam through a transition from svn to git.  Branch names are really\nimportant to people.  If they've decided to branch \"origin/master\" as\nsomething that's not called \"master\", there's a really good chance\nthat they mean it to be a new branch.  I think it's also really\nimportant to consider the consequences of getting it wrong under\neither scenario.\n\nIf a user does some work on his new \"features/frobnitz\" branch and\ndoes a \"git push\" only to find that his work has been committed to the\ncompany's master branch he will be confused, frustrated, and publicly\nembarrassed.  He then has to apologize and figure out how to revert\nthe changes.  I really don't see any scenario where that user ends up\nsaying \"oh yeah, I guess git was right and I was wrong.\"\n\nCompare that outcome to somebody who expects upstream behavior and\ngets current.  That person pushes \"features/frobnitz\" expecting to see\nhis changes appear on \"origin/master\", only to find that they didn't.\nInstead there's a new branch \"origin/features/frobnitz\".  Maybe it's\nnot what he expected but it's easy enough to understand.  He hasn't\ninconvenienced anybody else, so there's no need for apology.  He just\ntakes a look at the docs and figures out how to accomplish what he\nintended and deletes the branch he accidentally created.\n\nIt's this public vs. private embarrassment factor that motivated me to\nrecommend \"current\" as our company policy and most strongly convinces\nme that \"current\" is the right default.\n\nCheers,\n-Nathan\n\n-- \nhttp://n8gray.org\n"},{"id":"188271","messageId":"201203312348.q2VNmsmc015543@no.baka.org","threadId":"30086","inReplyTo":"CA+7g9JxK5DHj3vbdGgF2dEJxvn=_ZfjAv7Y+AL_P-aO1FVB6-w@mail.gmail.com","subject":"Re: push.default: current vs upstream","fromName":"Seth Robertson","fromEmail":"in-gitvger@baka.org","sentAt":"2012-03-31T23:48:54Z","receivedAt":"2012-03-31T23:48:54Z","isPatch":false,"sender":{"key":"in-gitvger@baka.org","avatar":null},"body":"\nIn message <CA+7g9JxK5DHj3vbdGgF2dEJxvn=_ZfjAv7Y+AL_P-aO1FVB6-w@mail.gmail.com>, Nathan Gray writes:\n\n    If a user does some work on his new \"features/frobnitz\" branch and\n    does a \"git push\" only to find that his work has been committed to the\n    company's master branch he will be confused, frustrated, and publicly\n    embarrassed.  He then has to apologize and figure out how to revert\n    the changes.  I really don't see any scenario where that user ends up\n    saying \"oh yeah, I guess git was right and I was wrong.\"\n\nWhen working with a single remote, I tend to agree with you (though\nsince I also think receive.denyDeletes should be on by default for\nshared repos the public humiliation of creating a branch when you did\nnot mean to might still exist but of course it will be less damaging\nto others) .  However, tracking really comes into its own when working\nwith multiple remotes.  Is creating a stumbling block between naïve\nuse and more sophisticated use really necessary?\n\nHowever, the current message for this use case could seem to be\ntweaked to take care of this:\n\n$ git branch BB origin/B\nBranch BB set up to track remote branch B from origin.\n\nAdd \"If you push your changes will go there.\"\nAnd \"See git branch --upstream to modify both settings\"\n\nThis provides the power of tracking with smaller possibility of\nthe type of embarrassment you envision.\n\n\t\t\t\t\t-Seth Robertson\n"},{"id":"188272","messageId":"7vehs8i420.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"201203312348.q2VNmsmc015543@no.baka.org","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-01T02:22:47Z","receivedAt":"2012-04-01T02:22:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seth Robertson <in-gitvger@baka.org> writes:\n\n> However, the current message for this use case could seem to be\n> tweaked to take care of this:\n>\n> $ git branch BB origin/B\n> Branch BB set up to track remote branch B from origin.\n>\n> Add \"If you push your changes will go there.\"\n\nBut you need to limit that only when push.default is set to \"upstream\",\nno?  Otherwise the message will be confusing the user.\n"},{"id":"188275","messageId":"CA+7g9Jy=JRV8mXd6fxja3k1g2Vss6YZotPzVPs9xsPr6uoCg+Q@mail.gmail.com","threadId":"30086","inReplyTo":"201203312348.q2VNmsmc015543@no.baka.org","subject":"Re: push.default: current vs upstream","fromName":"Nathan Gray","fromEmail":"n8gray@n8gray.org","sentAt":"2012-04-01T05:58:50Z","receivedAt":"2012-04-01T05:58:50Z","isPatch":false,"sender":{"key":"n8gray@n8gray.org","avatar":"https://avatars.githubusercontent.com/u/82794?v=4"},"body":"On Sat, Mar 31, 2012 at 4:48 PM, Seth Robertson <in-gitvger@baka.org> wrote:\n>\n> In message <CA+7g9JxK5DHj3vbdGgF2dEJxvn=_ZfjAv7Y+AL_P-aO1FVB6-w@mail.gmail.com>, Nathan Gray writes:\n>\n>    If a user does some work on his new \"features/frobnitz\" branch and\n>    does a \"git push\" only to find that his work has been committed to the\n>    company's master branch he will be confused, frustrated, and publicly\n>    embarrassed.  He then has to apologize and figure out how to revert\n>    the changes.  I really don't see any scenario where that user ends up\n>    saying \"oh yeah, I guess git was right and I was wrong.\"\n>\n> When working with a single remote, I tend to agree with you (though\n> since I also think receive.denyDeletes should be on by default for\n> shared repos the public humiliation of creating a branch when you did\n> not mean to might still exist but of course it will be less damaging\n> to others) .  However, tracking really comes into its own when working\n> with multiple remotes.  Is creating a stumbling block between naïve\n> use and more sophisticated use really necessary?\n\nWhere's the stumbling block?  Nobody's talking about taking away the\nupstream option, so sophisticated users who prefer upstream behavior\ncan configure their repos to get it.  The default should be tailored\nfor naïve users, not power users.\n\n> However, the current message for this use case could seem to be\n> tweaked to take care of this:\n>\n> $ git branch BB origin/B\n> Branch BB set up to track remote branch B from origin.\n>\n> Add \"If you push your changes will go there.\"\n> And \"See git branch --upstream to modify both settings\"\n>\n> This provides the power of tracking with smaller possibility of\n> the type of embarrassment you envision.\n\nI like the idea of telling users where their pushes will go, but I\ndon't think this will work as well as you might expect.  You're\nrelying on a new user to read every part of the message, understand\nthe terminology, and internalize the meaning well enough to remember\nit in the distant future when he's ready to push.  Considering the\nonslaught of new concepts to absorb when a user switches from\ncentralized to distributed SCM that's a pretty tall order.\n\nI think it's backwards to put a heavier cognitive load on newbies for\nthe sake of saving power users from running git config.  After all,\npower users *love* running git config.  ;^)\n\nCheers,\n-Nathan\n\n-- \nhttp://n8gray.org\n"},{"id":"188298","messageId":"vpqty12h995.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"7vty15ltuo.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-02T07:40:22Z","receivedAt":"2012-04-02T07:40:22Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Obviously the\n> former is much simpler to explain and understand, as people do not have to\n> learn upstream tracking before doing their first \"push\".\n\nAgain, this is simple only for people who never run \"git pull\" without\nargument.\n\nFor the others, they already have to learn about the \"upstream\"\nsemantics. And making argumentless \"git pull\" and \"git push\" purposely\nasymetric to make it simple for the user sounds like an oxymoron to me.\n\nThe discussion seems to focuse on 'let's make \"git push\" easy to\nexplain', but I think the right thing to do is to make _Git_ easy to\nexplain. With \"push.default = current\", we'll have a hard time\nexplaining how \"git pull\" works.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"188326","messageId":"7vlimegjw9.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"vpqty12h995.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-02T16:48:06Z","receivedAt":"2012-04-02T16:48:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Obviously the\n>> former is much simpler to explain and understand, as people do not have to\n>> learn upstream tracking before doing their first \"push\".\n>\n> Again, this is simple only for people who never run \"git pull\" without\n> argument.\n\nIf you are running \"git pull\" with what to pull and integrate, you know\nsystem much better than those who only use the canned \"git pull without\nargument\" settings, so customizing push.default should be easier for you\nthan the real beginners whom we try to avoid confusing with the built-in\ndefault, no?\n\nBefore saying \"again\", perhaps we should read and think about what the\nother side said.  I think [*1*] raises a good point.\n\n> For the others, they already have to learn about the \"upstream\"\n> semantics.\n\nBut the others have graduated from CVS/SVN mentality.  Also, \"upstream\"\nneeds to be carefully chosen; I suspect that it is not as trivial for the\nbeginners to wrap their mind around it as you seem to be implying.\n\nAfter a \"git clone\", you may want to work on whatever you are doing on\nyour topic branch, and then share it with your collaborator and polish it\nto be suitable for the master, you may want to do this:\n\n    git checkout -b topic ; work work work\n    git push origin topic\n\nBut if your work on topic is ready to be published for everybody, you may \njust do this:\n\n    git checkout -b topic ; work work work\n    git push origin master\n\nThe upstream of topic for the former case would be origin/topic while for\nthe latter case it would be origin/master.\n\nI and you know that.  But is the rest of the user experience set up to\neasily arrange this automatically?  With branch.autosetupmerge, I suspect\nthat the above can be generalized to:\n\n\tgit push origin master:topic ;# create the shared starting point\n\tgit checkout -b topic origin/topic ;# and fork it\n\n        repeat the three steps below 0 or more times\n          work work work\n          git push ;# goes to @{u} that is origin/topic\n          git pull ;# takes work by collaborators from @{u}\n\n\tgit push origin HEAD:master ;# topic is fully cooked, ready for master\n\nand everything *should* go smoothly when @{u} is set up correctly.  At\nleast, that was the plan for @{u} mechanism.\n\nThe last step that pushes \"git push origin HEAD:master\" *might* be simpler\nto explain if it were done this way:\n\n\tgit checkout master\n        git pull ;# syncs to the origin/master\n        git merge topic\n        git push\n\nAlso see Peff's 194414 in the same thread.\n\n[References]\n\n*1* http://thread.gmane.org/gmane.comp.version-control.git/194175/focus=194470\n"},{"id":"188332","messageId":"vpqy5qejbjl.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"7vlimegjw9.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-02T17:20:14Z","receivedAt":"2012-04-02T17:20:14Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>\n>> Junio C Hamano <gitster@pobox.com> writes:\n>>\n>>> Obviously the\n>>> former is much simpler to explain and understand, as people do not have to\n>>> learn upstream tracking before doing their first \"push\".\n>>\n>> Again, this is simple only for people who never run \"git pull\" without\n>> argument.\n>\n> If you are running \"git pull\" with what to pull and integrate, you know\n> system much better than those who only use the canned \"git pull without\n> argument\" settings, so customizing push.default should be easier for you\n> than the real beginners whom we try to avoid confusing with the built-in\n> default, no?\n\nI don't understand what you mean, sorry.\n\nI'll rephrase my point in case it wasn't clear. My claim is that a\nbeginner who want to run argumentless \"git pull\" has to understand where\nhis changes come from. So, he already has to understand what \"upstream\nbranch\" means to Git.\n\nI agree that explaining \"push.default=current\" is easy alone, but once\nyou've taught \"git pull\", explaining that \"git push\" does something else\nand why doesn't seem that easy to me. OTOH, once you understand \"git\npull\", explaining \"push.default=upstream\" should be as simple as \"send\nyour changes where git pull would get them\".\n\n> Before saying \"again\", perhaps we should read and think about what the\n> other side said.  I think [*1*] raises a good point.\n\n> *1* http://thread.gmane.org/gmane.comp.version-control.git/194175/focus=194470\n\nI think this message precisely supports my claim: we focus the\ndiscussion on \"git push\", without thinking on the big picture \"git pull\"\nAND \"git push\". The message you point to does not talk at all about \"git\npull\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"188338","messageId":"7vobraf057.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"vpqy5qejbjl.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-02T18:40:04Z","receivedAt":"2012-04-02T18:40:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Before saying \"again\", perhaps we should read and think about what the\n>> other side said.  I think [*1*] raises a good point.\n>\n>> *1* http://thread.gmane.org/gmane.comp.version-control.git/194175/focus=194470\n>\n> I think this message precisely supports my claim: we focus the\n> discussion on \"git push\", without thinking on the big picture \"git pull\"\n> AND \"git push\". The message you point to does not talk at all about \"git\n> pull\".\n\nI do not think so; that \"name\" argument is about this part from Peff's\nmessage, to which it is a response:\n\n>> > my two concerns is that this:\n>> >\n>> >   $ git clone ...\n>> >   $ git checkout -b topic origin/master\n>> >   $ hack hack hack\n>> >   $ git push\n>> >\n>> > will try to implicitly fast-forward merge your commits onto master.\n>> \n>> And the reason why it is surprising to the beginners is?  Because \"topic\"\n>> and \"master\" (of \"origin/master\") are not the same name?\n>\n> Sort of. It is more because \"upstream\" is an overloaded concept. Perhaps\n> you created the branch from origin/master because you wanted to say\n> \"this is where my topic is based, and when I 'rebase -i' later, I want\n> it to be considered the baseline\". Or perhaps you meant to say \"I am\n> going to work on origin's master branch, but I would prefer to call it\n> 'topic' here\".\n\nIf you re-read it, it should be clear that this is _also_ about \"git pull\";\n\"I am going to work on origin's master branch\" is about pushing the result\nback there.\n\nIn the former case, you may want to push it to 'topic' to work further\nwith your collaborators.  In the latter case, you would want to push it\nback to 'master', even though you are calling it locally 'topic' for some\nsick reason (read: because you can).\n"},{"id":"188340","messageId":"vpqwr5ydkqt.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"7vobraf057.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-02T18:58:02Z","receivedAt":"2012-04-02T18:58:02Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>\n>> Junio C Hamano <gitster@pobox.com> writes:\n>>\n>>> Before saying \"again\", perhaps we should read and think about what the\n>>> other side said.  I think [*1*] raises a good point.\n>>\n>>> *1* http://thread.gmane.org/gmane.comp.version-control.git/194175/focus=194470\n>>\n>> I think this message precisely supports my claim: we focus the\n>> discussion on \"git push\", without thinking on the big picture \"git pull\"\n>> AND \"git push\". The message you point to does not talk at all about \"git\n>> pull\".\n>\n> I do not think so; that \"name\" argument is about this part from Peff's\n> message, to which it is a response:\n\nWhat I read in the message is that branch names are important, and \"same\nname\" usually have some sort of semantics for users. I agree with that.\nBut why doesn't the same applies to \"git pull\"? Why would it be natural\nfor \"git pull\" to pull from a branch other than the one with the same\nname?\n\n>>> > my two concerns is that this:\n>>> >\n>>> >   $ git clone ...\n>>> >   $ git checkout -b topic origin/master\n>>> >   $ hack hack hack\n>>> >   $ git push\n>>> >\n>>> > will try to implicitly fast-forward merge your commits onto master.\n>>> \n>>> And the reason why it is surprising to the beginners is?  Because \"topic\"\n>>> and \"master\" (of \"origin/master\") are not the same name?\n>>\n>> Sort of. It is more because \"upstream\" is an overloaded concept. Perhaps\n>> you created the branch from origin/master because you wanted to say\n>> \"this is where my topic is based, and when I 'rebase -i' later, I want\n>> it to be considered the baseline\". Or perhaps you meant to say \"I am\n>> going to work on origin's master branch, but I would prefer to call it\n>> 'topic' here\".\n>\n> If you re-read it, it should be clear that this is _also_ about \"git pull\";\n> \"I am going to work on origin's master branch\" is about pushing the result\n> back there.\n\nThat's still not clear. Your explanation shows me how \"git push\" is\ninvolved, not \"git pull\".\n\n> In the former case, you may want to push it to 'topic' to work further\n> with your collaborators.  In the latter case, you would want to push it\n> back to 'master', even though you are calling it locally 'topic' for some\n> sick reason (read: because you can).\n\nI still don't see pull involved here.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"188343","messageId":"7vzkatex02.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"vpqwr5ydkqt.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-02T19:47:57Z","receivedAt":"2012-04-02T19:47:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> ...\n>> In the former case, you may want to push it to 'topic' to work further\n>> with your collaborators.  In the latter case, you would want to push it\n>> back to 'master', even though you are calling it locally 'topic' for some\n>> sick reason (read: because you can).\n>\n> I still don't see pull involved here.\n\nThink again.  Hint: realize that these people are not working alone, and\nwill be keeping their topic in sync with collaborators, and then imagine\nhow they are doing so.\n\nNo more words from me on this subthread.\n"},{"id":"188347","messageId":"vpqiphhdfzw.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"7vzkatex02.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-02T20:40:35Z","receivedAt":"2012-04-02T20:40:35Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> No more words from me on this subthread.\n\nIt's a pity. I still have no answer to my question:\n\n| But why doesn't the same applies to \"git pull\"? Why would it be natural\n| for \"git pull\" to pull from a branch other than the one with the same\n| name?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"188349","messageId":"7vmx6teu46.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"vpqiphhdfzw.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-02T20:50:17Z","receivedAt":"2012-04-02T20:50:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> No more words from me on this subthread.\n>\n> It's a pity. I still have no answer to my question:\n\nThat's OK.\n\nThe above is not \"I hate you enough that I won't talk to you\", but \"I\nrealize that I am not the best person to explain\".  You'll hopefully get\nresponses from those who prefer to see 'current' over 'upstream' ;-).\n"},{"id":"188353","messageId":"CANgJU+V57Yz2FXStsYtL38td7FLR=ihaKzvbOBqzbR=qEFgESw@mail.gmail.com","threadId":"30086","inReplyTo":"vpqiphhdfzw.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-04-02T21:02:53Z","receivedAt":"2012-04-02T21:02:53Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 2 April 2012 22:40, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> No more words from me on this subthread.\n>\n> It's a pity. I still have no answer to my question:\n>\n> | But why doesn't the same applies to \"git pull\"? Why would it be natural\n> | for \"git pull\" to pull from a branch other than the one with the same\n> | name?\n\nThe choice of \"fetch\" and \"pull\" and \"push\" were in some respects\nunfortunate. They sound like opposites, but they are not. The very\nfact that you have two commands \"pull\" and \"fetch\" both of which are\nmore or less the semantic opposites of \"push\" leads to confusion.\n\nAnd actually I find your use of \"git pull\" and \"pull\" in the\nexpression \"pull from a branch other than one with the same name\"\nconfusing. Barring misconfiguration pull operates on only one local\nbranch and it is usually the one with the same name. However push\noperates on multiple local branches. So from the point of view of\n\"what local branches are involved in the operation\" the current\ndefault leads to inconsistency.\n\nIf you had replaced \"pull\" with \"fetch\" then your argument somewhat\nmakes sense, but IMO is overriden by the observation that \"fetch\" is\nessentially non-destructive, it modifies only local copies of the\nremotes state, and even if you consider that destructive it is\ndestructive of your own data , push on the other hand *is* potentially\ndestructive, and destructive of data on a remote system.\n\nLastly I have never really encountered any confusion with explaining\nthe default behaviour of git-fetch, nor actually git-pull, but I have\nencountered lots of confusion of people using git-push.  They expect\ngit-push to be the opposite of git-pull not git-fetch.\n\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"188355","messageId":"vpqd37pbzqw.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"CANgJU+V57Yz2FXStsYtL38td7FLR=ihaKzvbOBqzbR=qEFgESw@mail.gmail.com","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-02T21:16:55Z","receivedAt":"2012-04-02T21:16:55Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"demerphq <demerphq@gmail.com> writes:\n\n> And actually I find your use of \"git pull\" and \"pull\" in the\n> expression \"pull from a branch other than one with the same name\"\n> confusing. Barring misconfiguration pull operates on only one local\n> branch and it is usually the one with the same name. However push\n> operates on multiple local branches.\n\nIt does with push.default = matching, but with either options we are\ndiscussing here, argumentless \"git push\" would push only one branch.\nThe choice we have is whether to push to the branch with the same name,\nor to the branch from which \"git pull\" would take the changes.\n\n(I realize that in this discussion, \"current\" may be misleading. I mean\n\"push.default=current\", not \"the behavior we have currently\")\n\n> Lastly I have never really encountered any confusion with explaining\n> the default behaviour of git-fetch, nor actually git-pull, but I have\n> encountered lots of confusion of people using git-push.  They expect\n> git-push to be the opposite of git-pull not git-fetch.\n\nI do also expect \"git pull\" to be symmetrical to \"git pull\", and\n\"push.default=upstream\" is the closest to symmetry.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"188433","messageId":"20120403205906.GB24815@sigill.intra.peff.net","threadId":"30086","inReplyTo":"7vlimhk7rz.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-03T20:59:07Z","receivedAt":"2012-04-03T20:59:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 30, 2012 at 04:07:12PM -0700, Junio C Hamano wrote:\n\n> There were two issues I raised in that message.  It turns out that we\n> already have the code for the first one.  The second one should look\n> something like this:\n> \n> -- >8 --\n> Subject: push: detect nonsense \"upstream\" check more carefully\n\nThanks, I think this is an improvement. I absolutely think the existing\nbehavior was a bug, but I do wonder if any users were depending on this\n\"feature\".\n\nSquashable tests are below.\n\n> +\tif (strcmp(branch->remote_name, remote->name)) {\n> +\t\tstruct remote *branch_dest = remote_get(branch->remote_name);\n> +\t\tconst char **branch_dest_url, **dest_url;\n> +\n> +\t\tif (!push_url_of_remote(remote, &dest_url) ||\n> +\t\t    !push_url_of_remote(branch_dest, &branch_dest_url) ||\n> +\t\t    strcmp(dest_url[0], branch_dest_url[0]))\n> +\t\t\tdie(_(\"You are pushing to remote '%s', which is not the \"\n> +\t\t\t      \"upstream of your\\ncurrent branch '%s'.\\n\"),\n> +\t\t\t    remote->name, branch->name);\n> +\t}\n\nHmm. So this will actually detect \"git push $URL\" when $URL matches the\nremote's configured URL. I feel like this distinction has come up\nbefore, and we decided not to equate the two. But now I can't remember\nwhere (maybe it when fetching via URL versus via remote?).\n\nWhat should happen if there are multiple push URLs configured? Your code\nwill match iff it is the first one. I would think it should either\nrequire all to match, or it should proceed if any of the URLs match.\nI think the latter makes more sense, though personally I would simply\nhave compared the remote names.\n\n-Peff\n\n---\nHere are the tests.\n\ndiff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\nnew file mode 100755\nindex 0000000..c334c51\n--- /dev/null\n+++ b/t/t5528-push-default.sh\n@@ -0,0 +1,54 @@\n+#!/bin/sh\n+\n+test_description='check various push.default settings'\n+. ./test-lib.sh\n+\n+test_expect_success 'setup bare remotes' '\n+\tgit init --bare repo1 &&\n+\tgit remote add parent1 repo1 &&\n+\tgit init --bare repo2 &&\n+\tgit remote add parent2 repo2 &&\n+\ttest_commit one &&\n+\tgit push parent1 HEAD &&\n+\tgit push parent2 HEAD\n+'\n+\n+test_expect_success '\"upstream\" pushes to configured upstream' '\n+\tgit checkout master &&\n+\ttest_config branch.master.remote parent1 &&\n+\ttest_config branch.master.merge refs/heads/foo &&\n+\ttest_config push.default upstream &&\n+\ttest_commit two &&\n+\tgit push &&\n+\techo two >expect &&\n+\tgit --git-dir=repo1 log -1 --format=%s foo >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success '\"upstream\" does not push on unconfigured remote' '\n+\tgit checkout master &&\n+\ttest_unconfig branch.master.remote &&\n+\ttest_config push.default upstream &&\n+\ttest_commit three &&\n+\ttest_must_fail git push\n+'\n+\n+test_expect_success '\"upstream\" does not push on unconfigured branch' '\n+\tgit checkout master &&\n+\ttest_config branch.master.remote parent1 &&\n+\ttest_unconfig branch.master.merge &&\n+\ttest_config push.default upstream\n+\ttest_commit four &&\n+\ttest_must_fail git push\n+'\n+\n+test_expect_success '\"upstream\" does not push when remotes do not match' '\n+\tgit checkout master &&\n+\ttest_config branch.master.remote parent1 &&\n+\ttest_config branch.master.merge refs/heads/foo &&\n+\ttest_config push.default upstream &&\n+\ttest_commit five &&\n+\ttest_must_fail git push parent2\n+'\n+\n+test_done\n"},{"id":"188435","messageId":"20120403210414.GC24815@sigill.intra.peff.net","threadId":"30086","inReplyTo":"20120403205906.GB24815@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-03T21:04:14Z","receivedAt":"2012-04-03T21:04:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 03, 2012 at 04:59:07PM -0400, Jeff King wrote:\n\n> > +\t\tif (!push_url_of_remote(remote, &dest_url) ||\n> > +\t\t    !push_url_of_remote(branch_dest, &branch_dest_url) ||\n> > +\t\t    strcmp(dest_url[0], branch_dest_url[0]))\n> > +\t\t\tdie(_(\"You are pushing to remote '%s', which is not the \"\n> > +\t\t\t      \"upstream of your\\ncurrent branch '%s'.\\n\"),\n> > +\t\t\t    remote->name, branch->name);\n> > +\t}\n> \n> Hmm. So this will actually detect \"git push $URL\" when $URL matches the\n> remote's configured URL. I feel like this distinction has come up\n> before, and we decided not to equate the two. But now I can't remember\n> where (maybe it when fetching via URL versus via remote?).\n> \n> What should happen if there are multiple push URLs configured? Your code\n> will match iff it is the first one. I would think it should either\n> require all to match, or it should proceed if any of the URLs match.\n> I think the latter makes more sense, though personally I would simply\n> have compared the remote names.\n\nIf this is the behavior we want, here are some squashable tests (on top\nof my other tests) to check the URL-matching, and to expose the\nmultiple-URL case.\n\n---\ndiff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\nindex c334c51..d809615 100755\n--- a/t/t5528-push-default.sh\n+++ b/t/t5528-push-default.sh\n@@ -51,4 +51,29 @@ test_expect_success '\"upstream\" does not push when remotes do not match' '\n \ttest_must_fail git push parent2\n '\n \n+test_expect_success '\"upstream\" remote-match checks URLs' '\n+\tgit checkout master &&\n+\ttest_config branch.master.remote parent1 &&\n+\ttest_config branch.master.merge refs/heads/foo &&\n+\ttest_config push.default upstream &&\n+\ttest_commit six &&\n+\tgit push repo1 &&\n+\techo six >expect &&\n+\tgit --git-dir=repo1 log -1 --format=%s foo >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_failure '\"upstream\" remote-match checks all URLs' '\n+\tgit checkout master &&\n+\tgit config --add remote.parent1.push repo2 &&\n+\ttest_config branch.master.remote parent1 &&\n+\ttest_config branch.master.merge refs/heads/foo &&\n+\ttest_config push.default upstream &&\n+\ttest_commit seven &&\n+\tgit push repo2 &&\n+\techo seven >expect &&\n+\tgit --git-dir=repo2 log -1 --format=%s foo >actual &&\n+\ttest_cmp expect actual\n+'\n+\n test_done\n"},{"id":"188447","messageId":"7vsjgkbga9.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120403205906.GB24815@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-03T22:29:34Z","receivedAt":"2012-04-03T22:29:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> +\tif (strcmp(branch->remote_name, remote->name)) {\n>> +\t\tstruct remote *branch_dest = remote_get(branch->remote_name);\n>> +\t\tconst char **branch_dest_url, **dest_url;\n>> +\n>> +\t\tif (!push_url_of_remote(remote, &dest_url) ||\n>> +\t\t    !push_url_of_remote(branch_dest, &branch_dest_url) ||\n>> +\t\t    strcmp(dest_url[0], branch_dest_url[0]))\n>> +\t\t\tdie(_(\"You are pushing to remote '%s', which is not the \"\n>> +\t\t\t      \"upstream of your\\ncurrent branch '%s'.\\n\"),\n>> +\t\t\t    remote->name, branch->name);\n>> +\t}\n>\n> Hmm. So this will actually detect \"git push $URL\" when $URL matches the\n> remote's configured URL. I feel like this distinction has come up\n> before, and we decided not to equate the two. But now I can't remember\n> where (maybe it when fetching via URL versus via remote?).\n>\n> What should happen if there are multiple push URLs configured?\n\nThis is me merely try to be extra nice without succeeding.\n\nPerhaps it was an ill-thought-out part of the patch.  The reasoning was\nthat when you know that your 'origin' is at $URL, it might be irritating\nif \"git push $URL\" did not do what \"git push origin\" did, but we can\nalways say 'origin' that is a remoteo nickname is different from $URL; a\nremote nickname does not have to be _only_ substitute of the URL, but it\ncan do more for you.  That would give you more incentive to define remotes\nthat you interact with often, while keeping the bare-metal flexibility\nwhen interacting with other remotes in a one-shot fashion.\n\nI personally would be perfectly fine if\n\n\t$ git push $URL\n\nthat does not say what to push out how, regardless of push.default\nsettings, errors out.\n\nThe same can be said when a remote has more than one URL to be pushed to.\n\nPersonally I do not care too much about it, but this is one more reason\nnot to support \"upstream\" over \"current\" as the default setting.\n"},{"id":"188461","messageId":"7vk41wbdrw.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"7vsjgkbga9.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-03T23:23:47Z","receivedAt":"2012-04-03T23:23:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jeff King <peff@peff.net> writes:\n> ...\n>> Hmm. So this will actually detect \"git push $URL\" when $URL matches the\n>> remote's configured URL. I feel like this distinction has come up\n>> before, and we decided not to equate the two. But now I can't remember\n>> where (maybe it when fetching via URL versus via remote?).\n>\n> This is me merely try to be extra nice without succeeding.\n\nAn obvious patch to remove the misguided \"be nice and try to see if URLs\nare the same\" bit should look like this.\n\n builtin/push.c |   15 ++++-----------\n 1 file changed, 4 insertions(+), 11 deletions(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 3e18cd3..765b19c 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -97,17 +97,10 @@ static void setup_push_upstream(struct remote *remote)\n \tif (branch->merge_nr != 1)\n \t\tdie(_(\"The current branch %s has multiple upstream branches, \"\n \t\t    \"refusing to push.\"), branch->name);\n-\tif (strcmp(branch->remote_name, remote->name)) {\n-\t\tstruct remote *branch_dest = remote_get(branch->remote_name);\n-\t\tconst char **branch_dest_url, **dest_url;\n-\n-\t\tif (!push_url_of_remote(remote, &dest_url) ||\n-\t\t    !push_url_of_remote(branch_dest, &branch_dest_url) ||\n-\t\t    strcmp(dest_url[0], branch_dest_url[0]))\n-\t\t\tdie(_(\"You are pushing to remote '%s', which is not the \"\n-\t\t\t      \"upstream of your\\ncurrent branch '%s'.\\n\"),\n-\t\t\t    remote->name, branch->name);\n-\t}\n+\tif (strcmp(branch->remote_name, remote->name))\n+\t\tdie(_(\"You are pushing to remote '%s', which is not the \"\n+\t\t      \"upstream of your\\ncurrent branch '%s'.\\n\"),\n+\t\t    remote->name, branch->name);\n \n \tstrbuf_addf(&refspec, \"%s:%s\", branch->name, branch->merge[0]->src);\n \tadd_refspec(refspec.buf);\n"},{"id":"188474","messageId":"CANgJU+VN26Lx1YBdfHvDY9W8Tifc2dsKMLFoyx9EhtO4pANAZw@mail.gmail.com","threadId":"30086","inReplyTo":"vpqd37pbzqw.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-04-04T07:57:31Z","receivedAt":"2012-04-04T07:57:31Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 2 April 2012 23:16, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:\n> demerphq <demerphq@gmail.com> writes:\n>\n>> And actually I find your use of \"git pull\" and \"pull\" in the\n>> expression \"pull from a branch other than one with the same name\"\n>> confusing. Barring misconfiguration pull operates on only one local\n>> branch and it is usually the one with the same name. However push\n>> operates on multiple local branches.\n>\n> It does with push.default = matching, but with either options we are\n> discussing here, argumentless \"git push\" would push only one branch.\n> The choice we have is whether to push to the branch with the same name,\n> or to the branch from which \"git pull\" would take the changes.\n\nAh, then I misunderstood your point. Probably because of the point you\nmake next.\n\n> (I realize that in this discussion, \"current\" may be misleading. I mean\n> \"push.default=current\", not \"the behavior we have currently\")\n>\n>> Lastly I have never really encountered any confusion with explaining\n>> the default behaviour of git-fetch, nor actually git-pull, but I have\n>> encountered lots of confusion of people using git-push.  They expect\n>> git-push to be the opposite of git-pull not git-fetch.\n>\n> I do also expect \"git pull\" to be symmetrical to \"git pull\", and\n> \"push.default=upstream\" is the closest to symmetry.\n\nAfter clarifying what he meant off-list I'd just like to say that I\nagree with Matthieu. Picking a default that makes git-push not be the\nopposite of git-pull will end up surprising some people some of the\ntime. Enough that I suspect that this conversation will be coming up\nagain in the future.\n\ncheers,\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"188558","messageId":"20120405124539.GA10293@sigill.intra.peff.net","threadId":"30086","inReplyTo":"7vsjgkbga9.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-05T12:45:39Z","receivedAt":"2012-04-05T12:45:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 03, 2012 at 03:29:34PM -0700, Junio C Hamano wrote:\n\n> > Hmm. So this will actually detect \"git push $URL\" when $URL matches the\n> > remote's configured URL. I feel like this distinction has come up\n> > before, and we decided not to equate the two. But now I can't remember\n> > where (maybe it when fetching via URL versus via remote?).\n> >\n> > What should happen if there are multiple push URLs configured?\n> \n> This is me merely try to be extra nice without succeeding.\n> \n> Perhaps it was an ill-thought-out part of the patch.  The reasoning was\n> that when you know that your 'origin' is at $URL, it might be irritating\n> if \"git push $URL\" did not do what \"git push origin\" did, but we can\n> always say 'origin' that is a remoteo nickname is different from $URL; a\n> remote nickname does not have to be _only_ substitute of the URL, but it\n> can do more for you.  That would give you more incentive to define remotes\n> that you interact with often, while keeping the bare-metal flexibility\n> when interacting with other remotes in a one-shot fashion.\n\nYeah, this better matches what we do with fetching, where \"git fetch\norigin\" will respect remote.origin.fetch, but \"git fetch $(git config\nremote.origin.url)\" will not. I do not care too much which way we go,\nbut I think that it makes sense to be consistent in the two cases.\n\n> I personally would be perfectly fine if\n> \n> \t$ git push $URL\n> \n> that does not say what to push out how, regardless of push.default\n> settings, errors out.\n> \n> The same can be said when a remote has more than one URL to be pushed to.\n\nI actually think \"git push $URL\" makes sense for 'current' and\n'matching'. I don't think people tend to do a lot of one-off pushes, but\ncertainly I have done:\n\n  $ git init\n  $ hack hack hack\n  $ commit commit commit\n  $ ssh example.com git init --bare foo.git\n  $ git push example.com:foo.git\n\n(and sometimes even followed by \"cd .. && rm -rf foo\", if my next step\nis to actually clone foo.git somewhere else).  Having to say \"HEAD\" or\n\":\" is not the end of the world (and in fact 'matching' already errors\nout in this case), but it's nice to do the right thing when it's obvious\n(i.e., for 'current').\n\n> Personally I do not care too much about it, but this is one more reason\n> not to support \"upstream\" over \"current\" as the default setting.\n\nAgreed.\n\n-Peff\n"},{"id":"188561","messageId":"20120405131301.GB10293@sigill.intra.peff.net","threadId":"30086","inReplyTo":"vpqty12h995.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-05T13:13:01Z","receivedAt":"2012-04-05T13:13:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 02, 2012 at 09:40:22AM +0200, Matthieu Moy wrote:\n\n> For the others, they already have to learn about the \"upstream\"\n> semantics. And making argumentless \"git pull\" and \"git push\" purposely\n> asymetric to make it simple for the user sounds like an oxymoron to me.\n\nWe can make the operations technically symmetric in terms of the actual\nsources and destinations from which commits are moved, but they are not\nnecessarily symmetric in the user's workflow.\n\nLet's imagine I have a branch \"topic\" that has an upstream of\n\"origin/master\". You are arguing that \"git pull\" moves commits from\n\"origin/master\" onto \"topic\", and therefore \"git push\" should move\ncommits from \"topic\" onto \"origin/master\". That is symmetric at a low\nlevel.\n\nBut what does it mean to me as a user? Those operations may not be\nsymmetric in my workflow if the branches have special meaning. For a\nproject using a topic-branch workflow, it is not big deal to move\ncommits from master onto a topic branch. But it _is_ a big deal to move\ncommits from a topic branch onto master, because that has social\nimplications within the project (e.g., saying \"this topic is ready for\nprime-time\").\n\nSo yeah, the low-level symmetry provides one nice way of explaining\nthose commands when the symmetry is helpful to your workflow. But I'm\nconcerned about the cases where what the user wants _isn't_ symmetric.\nWhen they say \"git push\" because they want to publish their topic\nbranch, and it does an embarrassing and difficult-to-revert thing to the\npublic master branch. Telling them \"ah, but you should have seen that\npull and push are symmetric! It all makes sense!\" is going to be small\nconsolation.\n\nFundamentally I am less concerned about explainibility and more about\nsafety when somebody has not even gotten to the point of having the\nthing explained.\n\n> The discussion seems to focuse on 'let's make \"git push\" easy to\n> explain', but I think the right thing to do is to make _Git_ easy to\n> explain. With \"push.default = current\", we'll have a hard time\n> explaining how \"git pull\" works.\n\nDo we have a hard time explaining how \"git pull\" works now?\n\n-Peff\n"},{"id":"188572","messageId":"vpqwr5uceis.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"20120405131301.GB10293@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-05T16:46:51Z","receivedAt":"2012-04-05T16:46:51Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Mon, Apr 02, 2012 at 09:40:22AM +0200, Matthieu Moy wrote:\n>\n>> For the others, they already have to learn about the \"upstream\"\n>> semantics. And making argumentless \"git pull\" and \"git push\" purposely\n>> asymetric to make it simple for the user sounds like an oxymoron to me.\n>\n> We can make the operations technically symmetric in terms of the actual\n> sources and destinations from which commits are moved, but they are not\n> necessarily symmetric in the user's workflow.\n\nIt seems rather natural to me to have \"asymetric workflow, asymetric\ncommands\" by default. So, if one wants to push to a place other than\nupstream, say \"git push public-repo branch\", or set your upstream to\nwhere you want to push (simple with \"git push -u\"), and say explicitely\n\"git pull repo branch\".\n\nI can hardly imagine someone knowing what \"git pull\" does, and\n_surprised_ to see that \"git push\" sends commits to the same place. I\nagree that sending commits to upstream may be a mistake, but I don't\nthink it can happen \"by surprise\".\n\nThere are also ways to shoot yourself in the foot with when setting\nupstream to something other that where you usually push. For example,\nrun \"git rebase -i\" without argument, and it will offer you to rewrite\nsome published history. \"git pull --rebase\" also becomes a potentially\ndangerous operation, while it's normally harmless with\n'push.default=upstream'.\n\nAnd I still have my concern with real beginners: what advice would you\ngive to a user whose \"git push\" is denied because of non-fast forward. I\nraised this concern already:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=193196\n\nand I essentially had the answer \"telling the user to pull is wrong\"\n(with which I disagree), but no one managed to give another advice.\n\nWith real-real-newbies, this is my number 1 issue (they don't even do\nbranches, they just run push, git tells them to pull, and they come to\nme saying \"git is broken, we can't work\"). With not-so-newbies, I have\nless experience ;-).\n\n>> The discussion seems to focuse on 'let's make \"git push\" easy to\n>> explain', but I think the right thing to do is to make _Git_ easy to\n>> explain. With \"push.default = current\", we'll have a hard time\n>> explaining how \"git pull\" works.\n>\n> Do we have a hard time explaining how \"git pull\" works now?\n\nI don't think so, but Junio's argument is that explaining what push\nwould do with 'upstream' would be too complex, and that 'current' is\neasier to explain. If 'git pull' is simple, then 'git -c\npush.current=upstream push' is equally simple.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"188637","messageId":"20120406071520.GD25301@sigill.intra.peff.net","threadId":"30086","inReplyTo":"vpqwr5uceis.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-06T07:15:20Z","receivedAt":"2012-04-06T07:15:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 05, 2012 at 06:46:51PM +0200, Matthieu Moy wrote:\n\n> It seems rather natural to me to have \"asymetric workflow, asymetric\n> commands\" by default. So, if one wants to push to a place other than\n> upstream, say \"git push public-repo branch\", or set your upstream to\n> where you want to push (simple with \"git push -u\"), and say explicitely\n> \"git pull repo branch\".\n\nThat makes sense _if_ the user is thinking about pull and push as\nsymmetric commands. That may be immediately obvious for some people's\nmental models. But I suspect it is not for others (it is not for mine,\nthough I obviously do not count as a beginner).\n\n> I can hardly imagine someone knowing what \"git pull\" does, and\n> _surprised_ to see that \"git push\" sends commits to the same place. I\n> agree that sending commits to upstream may be a mistake, but I don't\n> think it can happen \"by surprise\".\n\nYou are asking the new user to make a logical inference about the\nrelationship between push and pull. That inference may seem obvious to\nyou, and it may even be obvious to a large portion of new users. But\nkeep in mind that we are not debating whether \"upstream\" is a reasonable\nthing for git to have, but rather whether it is a good default.  My\nconcern is that upstream as a default would have negligible benefit for\npeople who do make the inference, but be dangerous for the group who do\nnot. We don't know the size of the latter, but my feeling is that it is\nnon-trivial.\n\n> There are also ways to shoot yourself in the foot with when setting\n> upstream to something other that where you usually push. For example,\n> run \"git rebase -i\" without argument, and it will offer you to rewrite\n> some published history.\n\nYes, although that is often what you want in such a setup (e.g., you are\nrebasing on top of the upstream branch, but publishing your work in\nprogress).  However, I do agree that it can potentially be dangerous.\nTwo helpful saving graces are:\n\n  1. The first thing you see upon \"git rebase -i\" is a giant list of the\n     commits from your upstream branch. It is usually quite obvious that\n     you are rebasing more than you want in this case, and you can abort\n     before doing anything.\n\n  2. Even if you do rebase, you have made a _local_ error. You are not\n     hurting anyone until you push, at which point you will get a\n     non-fast-forward error, and you have a chance to fix things before\n     disrupting other people.\n\n> And I still have my concern with real beginners: what advice would you\n> give to a user whose \"git push\" is denied because of non-fast forward. I\n> raised this concern already:\n> \n>   http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=193196\n> \n> and I essentially had the answer \"telling the user to pull is wrong\"\n> (with which I disagree), but no one managed to give another advice.\n\nIt _is_ wrong unless the destination branch is also the configured\nupstream. Which yes, it probably is if push.default is \"upstream\".\nUnless you actually specified a push destination, in which case it may\nnot be. Or if you were pushing something besides HEAD.\n\nIf the push destination was $remote:$branch, it seems the only correct\nthing is to suggest \"git pull $remote $branch\" in the general case, and\npossibly simplify that to \"git pull\" if $remote:$branch is the\nconfigured upstream. And if the source was HEAD, of course; otherwise\nyou would need to checkout.\n\nSo shouldn't the advice for a non-fast-forward push be:\n\n   if $source_ref is currently checked out\n           advise \"git checkout $source_ref, and then...\"\n   fi\n   if $dest_remote == branch.$source_ref.remote &&\n      $dest_ref == branch.$source_ref.merge\n           advise \"git pull\"\n   else\n           advise \"git pull $dest_remote $dest_ref\"\n   fi\n\nThat handles only one ref, of course. If you get multiple non-ff\nfailures, I'm not sure what we should advise.\n\n> >> The discussion seems to focuse on 'let's make \"git push\" easy to\n> >> explain', but I think the right thing to do is to make _Git_ easy to\n> >> explain. With \"push.default = current\", we'll have a hard time\n> >> explaining how \"git pull\" works.\n> >\n> > Do we have a hard time explaining how \"git pull\" works now?\n> \n> I don't think so, but Junio's argument is that explaining what push\n> would do with 'upstream' would be too complex, and that 'current' is\n> easier to explain. If 'git pull' is simple, then 'git -c\n> push.current=upstream push' is equally simple.\n\nYou wrote above that we'll have a hard time explaining how \"git pull\"\nworks. But I don't think so; if it hasn't been a problem with\n\"matching\", then why would it with \"current\"?\n\nI agree that your symmetry explanation is reasonably simple for\nexplaining what \"git push\" will do for new users (though I also think\n\"current\" is quite easy to explain). I'm less concerned with explaining\nand more concerned about safe defaults.\n\n-Peff\n"},{"id":"188641","messageId":"vpqr4w12tjj.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"20120406071520.GD25301@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-06T07:44:48Z","receivedAt":"2012-04-06T07:44:48Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Thu, Apr 05, 2012 at 06:46:51PM +0200, Matthieu Moy wrote:\n>\n>> It seems rather natural to me to have \"asymetric workflow, asymetric\n>> commands\" by default. So, if one wants to push to a place other than\n>> upstream, say \"git push public-repo branch\", or set your upstream to\n>> where you want to push (simple with \"git push -u\"), and say explicitely\n>> \"git pull repo branch\".\n>\n> That makes sense _if_ the user is thinking about pull and push as\n> symmetric commands. That may be immediately obvious for some people's\n> mental models. But I suspect it is not for others (it is not for mine,\n> though I obviously do not count as a beginner).\n\nI think exactly the opposite. Once you learnt about remote-tracking\nbranches, about \"git fetch\" Vs \"git pull\", you understand why \"git pull\"\nand \"git push\" are not strictly speaking symmetrical operations.\n\nBut just from the wording, it should be obvious that the commands are\ndoing something somehow symmetrical.\n\n> So shouldn't the advice for a non-fast-forward push be:\n>\n>    if $source_ref is currently checked out\n>            advise \"git checkout $source_ref, and then...\"\n>    fi\n>    if $dest_remote == branch.$source_ref.remote &&\n>       $dest_ref == branch.$source_ref.merge\n>            advise \"git pull\"\n>    else\n>            advise \"git pull $dest_remote $dest_ref\"\n>    fi\n>\n> That handles only one ref, of course. If you get multiple non-ff\n> failures, I'm not sure what we should advise.\n\nThe topic ct/advise-push-default does essentially that indeed.\n\n> You wrote above that we'll have a hard time explaining how \"git pull\"\n> works. But I don't think so; if it hasn't been a problem with\n> \"matching\", then why would it with \"current\"?\n\nI mis-spoke. I think I meant something like \"if the assumption that\nexplaining push -c push.current=upstream is hard, then we'll have a hard\ntime explaining git pull\".\n\n> I'm less concerned with explaining and more concerned about safe\n> defaults.\n\nYes, my rant about simplicity was a reply to Junio, who was arguing\nabout simplicity:\n\nJunio C Hamano writes:\n\n| Obviously the former [\"current\"] is much simpler to explain and understand, as\n| people do not have to learn upstream tracking before doing their first\n| \"push\".\n\nYour arguments about safety are valid (we don't agree on the relative\nimportance), but I think the argument of simplicity simply doesn't hold.\n\nAbout safety, I don't think we can tell in general which bad push is the\nmost serious. push.default=current may create branches unexpectedly,\nwhile push.default=upstream would ask you to \"push --set-upstream\" when\ncreating the remote branch. push.default=upstream may push to the master\nwhen you wanted to create a remote topic branch. My feeling is that both\nare equally bad, but maybe I'm wrong here.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"188642","messageId":"20120406080004.GA27940@sigill.intra.peff.net","threadId":"30086","inReplyTo":"vpqr4w12tjj.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-06T08:00:04Z","receivedAt":"2012-04-06T08:00:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 06, 2012 at 09:44:48AM +0200, Matthieu Moy wrote:\n\n> I think exactly the opposite. Once you learnt about remote-tracking\n> branches, about \"git fetch\" Vs \"git pull\", you understand why \"git pull\"\n> and \"git push\" are not strictly speaking symmetrical operations.\n> \n> But just from the wording, it should be obvious that the commands are\n> doing something somehow symmetrical.\n\nMy mind may be warped from too much git and I may be misremembering my\nearly days, but I feel like I never considered \"push\" and \"pull\" to be\nsymmetric opposites. I dunno. We are both talking about some\nhypothetical population of new users, and I'm not sure either of us has\nhard data.\n\n> > So shouldn't the advice for a non-fast-forward push be:\n> >\n> >    if $source_ref is currently checked out\n> >            advise \"git checkout $source_ref, and then...\"\n> >    fi\n> >    if $dest_remote == branch.$source_ref.remote &&\n> >       $dest_ref == branch.$source_ref.merge\n> >            advise \"git pull\"\n> >    else\n> >            advise \"git pull $dest_remote $dest_ref\"\n> >    fi\n> >\n> > That handles only one ref, of course. If you get multiple non-ff\n> > failures, I'm not sure what we should advise.\n> \n> The topic ct/advise-push-default does essentially that indeed.\n\nI think it does the first half (recommend checkout if it was a non-HEAD). But\nthe \"pull before push\" message just says:\n\n  Updates were rejected because the tip of your current branch is behind\n  its remote counterpart. Merge the remote changes (e.g. 'git pull')\n  before pushing again.\n\nwhich is not exactly right. Saying \"e.g.\" lets clueful people know that\nthe details of merging might be different, but I doubt that subtlety is\nhelpful for new users.\n\n> > You wrote above that we'll have a hard time explaining how \"git pull\"\n> > works. But I don't think so; if it hasn't been a problem with\n> > \"matching\", then why would it with \"current\"?\n> \n> I mis-spoke. I think I meant something like \"if the assumption that\n> explaining push -c push.current=upstream is hard, then we'll have a hard\n> time explaining git pull\".\n\nThat makes more sense to me.\n\n> About safety, I don't think we can tell in general which bad push is the\n> most serious. push.default=current may create branches unexpectedly,\n> while push.default=upstream would ask you to \"push --set-upstream\" when\n> creating the remote branch. push.default=upstream may push to the master\n> when you wanted to create a remote topic branch. My feeling is that both\n> are equally bad, but maybe I'm wrong here.\n\nI would say without hesitation that fast-forwarding the upstream is more\nlikely to be disastrous than creating a new branch. However,\npush.default=current can also fast-forward an existing branch (although\nif you have a local \"foo\" and its upstream is _not_ the remote \"foo\", I\nfind it extremely unlikely that a remote \"foo\" also exists).\n\nOn the other hand, one thing we have not talked about is how one gets\ninto the \"topic push fast-forwards master\" situation. Which is running:\n\n  $ git checkout -b topic origin/master\n\nI'm not sure if that is something totally clueless people will run. And\nmaybe by the time people are intermediate enough git users to run that,\nthey will have figured out how upstream works. So maybe my concern is\noverblown.  I consider the much more likely scenarios for a new user to\nbe:\n\n  $ git clone ... && cd project\n  $ hack hack hack\n  $ git push\n\nwhich will work with either \"current\" or \"upstream\", or:\n\n  $ git clone ... && cd project\n  $ git checkout foo ;# equivalent of \"git checkout -b foo origin/foo\"\n  $ hack hack hack\n  $ git push\n\nwhich also works with both, or:\n\n  $ git clone ... && cd project\n  $ git checkout -b topic\n  $ hack hack hack\n  $ git push\n\nwhich will error out for \"upstream\", and create a new branch \"topic\" on\nthe remote with \"current\".\n\n-Peff\n"},{"id":"188650","messageId":"CAHkcotjrVqvYnAV5U7gPngbW0saghAv8vZB3jh=dOKLPmYdJrQ@mail.gmail.com","threadId":"30086","inReplyTo":"vpqwr5uceis.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2012-04-06T11:38:24Z","receivedAt":"2012-04-06T11:38:24Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Apr 5, 2012 at 8:46 PM, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n>\n> I can hardly imagine someone knowing what \"git pull\" does, and\n> _surprised_ to see that \"git push\" sends commits to the same place.\n\nIt seems you assume that people use in a _centralized_ workflow.\nIn this case, 'upstream' does largely the right thing, so no one\nwill be surprised.\n\nHowever, many of those who got used to a distributed workflow will find\nthat surprising, because when they created a new branch that meant it\nto push as a _new_ branch. So other people could take a look, or they\nmay need the maintainer ACK to push anything to 'master'. Also they may\nhave a policy nothing should be fast-forwarded to master, but only to\nbe merged with a merge commit.\n\nAnd then it is more natural for people to think in terms of names that\nare immediately obvious to anyone, while 'upstream' behavior depends on\nthe state that is not immediately obvious. You may start a new topic\nbranch based on 'master' or some the latest release to have a more\nstable base. And 'upstream' will work differently in this case. If you\nknow about 'tracking' then it may be obvious to you, but it is not so\nobvious to those who only start to use git for short time...\n\n\n>\n> And I still have my concern with real beginners: what advice would you\n> give to a user whose \"git push\" is denied because of non-fast forward. I\n> raised this concern already:\n\nDon't use a central workflow, because it sucks :)\n\nSeriously, why do you care about beginners who use a centralized workflow\nand not beginners who have to use with existing projects that use more or\nless distributed workflow, where pushing to 'master' is more likely to be\nthe wrong thing to do than otherwise... And when push is denied, they may\nask someone whether they are doing something wrong. In case when master\nis fast-forwarded silently, they are not likely to notice that they did\nsomething wrong, and the fact that happens only sometimes (depending on\nsome \"tracking\" feature which they have not heard) is not very helpful.\n\n\nDmitry\n"},{"id":"188656","messageId":"CANgJU+VM4Dz3-EGa6z4hB8hB7ZvaahrG8tb5VCCzWQ=7zohBFA@mail.gmail.com","threadId":"30086","inReplyTo":"CAHkcotjrVqvYnAV5U7gPngbW0saghAv8vZB3jh=dOKLPmYdJrQ@mail.gmail.com","subject":"Re: push.default: current vs upstream","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-04-06T13:36:18Z","receivedAt":"2012-04-06T13:36:18Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 6 April 2012 13:38, Dmitry Potapov <dpotapov@gmail.com> wrote:\n> Seriously, why do you care about beginners who use a centralized workflow\n> and not beginners who have to use with existing projects that use more or\n> less distributed workflow,\n\nBecause the former are unlikely to be self-selected users of git and\ninstead are likely to be forced to use git because their $work has\ndictated it to be so. The self-selected users of git IMO would tend to\nboth have the motivation and the basic skills to learn whatever they\nneed and are unlikely to blame their mistakes on git. The ones forced\nto use git are *very* likely to say \"git is broken\", or \"git doesn't\nwork\" and then start arguing that \"cvs never had that problem\". Do you\nreally want a bunch of users of your software thinking CVS was\nsuperior?\n\nI would say the right default is the one that keeps idiot users happy,\nand has the least \"out of the box surprises\" for them. The smart ones\nwill figure things out anyway and configure their tools appropriately.\n\ncheers\nYves\n\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"188669","messageId":"7vk41s21w9.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120406080004.GA27940@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-06T17:41:58Z","receivedAt":"2012-04-06T17:41:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I would say without hesitation that fast-forwarding the upstream is more\n> likely to be disastrous than creating a new branch. However,\n> push.default=current can also fast-forward an existing branch (although\n> if you have a local \"foo\" and its upstream is _not_ the remote \"foo\", I\n> find it extremely unlikely that a remote \"foo\" also exists).\n>\n> On the other hand, one thing we have not talked about is how one gets\n> into the \"topic push fast-forwards master\" situation. Which is running:\n>\n>   $ git checkout -b topic origin/master\n>\n> I'm not sure if that is something totally clueless people will run. And\n> maybe by the time people are intermediate enough git users to run that,\n> they will have figured out how upstream works. So maybe my concern is\n> overblown....\n\nI already said that I do not deeply care either way, and it appears that\nonly you two are the ones who deeply care *and* have things to say that\nare worth listening to (we've seen many \"me too wants upstream\" without\ndeep thought a few weeks ago against the RFD).  Whichever way you two\nagree to go eventually, could you come up with a (hopefully) small summary\nof caveats that can be pasted in the future release notes that switches\nthe default away from the matching?\n\nE.g. \"The new default is now 'upstream', which does mostly what new people\ndo, but the user should not allow the default kick in in these situations:\nA, B, C...\"  It might end up saying \"The new default is now 'current',...\"\nbut the point is that either semantics would need to come with a warning.\n\nThanks.\n"},{"id":"188671","messageId":"jlnb1k$rdn$1@dough.gmane.org","threadId":"30086","inReplyTo":"20120406080004.GA27940@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Jehan Bing","fromEmail":"jehan@orb.com","sentAt":"2012-04-06T18:01:31Z","receivedAt":"2012-04-06T18:01:31Z","isPatch":false,"sender":{"key":"jehan@orb.com","avatar":null},"body":"On 2012-04-06 01:00, Jeff King wrote:\n> On the other hand, one thing we have not talked about is how one gets\n> into the \"topic push fast-forwards master\" situation. Which is running:\n>\n>   $ git checkout -b topic origin/master\n\nThat's what I was starting to think myself. This whole discussion about \n\"current\" is that it may not a good choice because \"push\" will not \nbehave like \"pull\". But I believe the real problem is that _pull_ \ndoesn't behave like _push_.\n\nIn other word, maybe \"git checkout -b topic origin/master\" shouldn't \ncreate a tracking branch in the first place (unless one uses \"--track\" \nor that some config setting has been explicitly set).\nOr more precisely, I believe it should be create a tracking branch only \nif the local branch name is the same as the remote's branch.\n(And the same for \"git branch <local> origin/<remote>\" of course)\n\nHow many newbies/clueless people will think that a branch \"topic\" tracks \na branch \"origin/master\"? And how many of these same people will think \nthat a branch \"topic\" doesn't track a branch \"origin/topic\"? For that \nmatter, that's how I use git myself. And until it's easy to see what \nbranch tracks what (i.e. until \"git branch\" shows the tracking \nbranches), I don't want to think differently because it's just too risky.\n\nSo for the \"me too\" votes:\n- +1 to change change \"push.default\" to current\n- +1 to change \"git checkout -b\" to not create a tracking branch unless \nthe local name matches the remote name .\n"},{"id":"188673","messageId":"CAHkcotgiNyaSRr-AH2j7GXjwXVSKToegZbycLWitv1tEfW6uSg@mail.gmail.com","threadId":"30086","inReplyTo":"CANgJU+VM4Dz3-EGa6z4hB8hB7ZvaahrG8tb5VCCzWQ=7zohBFA@mail.gmail.com","subject":"Re: push.default: current vs upstream","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2012-04-06T18:03:25Z","receivedAt":"2012-04-06T18:03:25Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Apr 6, 2012 at 5:36 PM, demerphq <demerphq@gmail.com> wrote:\n> On 6 April 2012 13:38, Dmitry Potapov <dpotapov@gmail.com> wrote:\n>> Seriously, why do you care about beginners who use a centralized workflow\n>> and not beginners who have to use with existing projects that use more or\n>> less distributed workflow,\n>\n> Because the former are unlikely to be self-selected users of git and\n> instead are likely to be forced to use git because their $work has\n> dictated it to be so.\n\nAny decision is made by people. On its own, $work does not dictate what\nVCS or what workflow should be used. There are many ways for those who\nare in charge to screw up things. And a centralized workflow is not very\nscalable and many bad practices associated with it. While it is not easy\nto to convert a CVS/SVN repository to git that alone does not bring most\nof git advantages, because those advantages come from the workflow.\n\n> The self-selected users of git IMO would tend to\n> both have the motivation and the basic skills to learn whatever they\n> need and are unlikely to blame their mistakes on git. The ones forced\n> to use git are *very* likely to say \"git is broken\", or \"git doesn't\n> work\" and then start arguing that \"cvs never had that problem\". Do you\n> really want a bunch of users of your software thinking CVS was\n> superior?\n\nGit is a distributed version control system. There is another VCS whose\nwhole designed was dictated by being a better CVS. It's called SVN and\nif someone is happy with it, why do not use it?\n\nI think git default settings should respect the main goal of git design:\na good support of a distributed workflow. Certainly git can be used in\nmany other ways: some people use it with a centralized workflow, some\nuse it to back up their configuration files, etc.. But those usage\nshould not dictate the default settings for git.\n\nDmitry\n"},{"id":"188676","messageId":"CANgJU+Wse2ej5tJmLnP54_Fx+A9O_UTK6zuLThdQDnnK5TWc4w@mail.gmail.com","threadId":"30086","inReplyTo":"CAHkcotgiNyaSRr-AH2j7GXjwXVSKToegZbycLWitv1tEfW6uSg@mail.gmail.com","subject":"Re: push.default: current vs upstream","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-04-06T18:48:31Z","receivedAt":"2012-04-06T18:48:31Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 6 April 2012 20:03, Dmitry Potapov <dpotapov@gmail.com> wrote:\n> On Fri, Apr 6, 2012 at 5:36 PM, demerphq <demerphq@gmail.com> wrote:\n>> On 6 April 2012 13:38, Dmitry Potapov <dpotapov@gmail.com> wrote:\n>>> Seriously, why do you care about beginners who use a centralized workflow\n>>> and not beginners who have to use with existing projects that use more or\n>>> less distributed workflow,\n>>\n>> Because the former are unlikely to be self-selected users of git and\n>> instead are likely to be forced to use git because their $work has\n>> dictated it to be so.\n>\n> Any decision is made by people. On its own, $work does not dictate what\n> VCS or what workflow should be used. There are many ways for those who\n> are in charge to screw up things. And a centralized workflow is not very\n> scalable and many bad practices associated with it. While it is not easy\n> to to convert a CVS/SVN repository to git that alone does not bring most\n> of git advantages, because those advantages come from the workflow.\n\nPretty well every project that uses git has a \"canonical upstream\nrepository\". Including for instance this one. Which basically means at\nsome point there is a centralized master repo. It is either owned by\nsomeone like Linus or Junio, or it is owned by a company. Companies\ntend to like to know that their valuable data is properly backed up,\nand etc. This basically means central repos are inevitable. And git\nworks just fine like that thank you very much.\n\n>> The self-selected users of git IMO would tend to\n>> both have the motivation and the basic skills to learn whatever they\n>> need and are unlikely to blame their mistakes on git. The ones forced\n>> to use git are *very* likely to say \"git is broken\", or \"git doesn't\n>> work\" and then start arguing that \"cvs never had that problem\". Do you\n>> really want a bunch of users of your software thinking CVS was\n>> superior?\n>\n> Git is a distributed version control system. There is another VCS whose\n> whole designed was dictated by being a better CVS. It's called SVN and\n> if someone is happy with it, why do not use it?\n\nBecause it sucks.\n\n> I think git default settings should respect the main goal of git design:\n> a good support of a distributed workflow. Certainly git can be used in\n> many other ways: some people use it with a centralized workflow, some\n> use it to back up their configuration files, etc.. But those usage\n> should not dictate the default settings for git.\n\nI stick to my original point, it should be aimed at making dumb people\nhappy. The rest will sort themselves out.\n\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"188681","messageId":"CAHkcotixA=NukMZYymjGQG+h5b9_6+5T13f4158rxKB1iAX-aw@mail.gmail.com","threadId":"30086","inReplyTo":"CANgJU+Wse2ej5tJmLnP54_Fx+A9O_UTK6zuLThdQDnnK5TWc4w@mail.gmail.com","subject":"Re: push.default: current vs upstream","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2012-04-06T19:38:46Z","receivedAt":"2012-04-06T19:38:46Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Apr 6, 2012 at 10:48 PM, demerphq <demerphq@gmail.com> wrote:\n> On 6 April 2012 20:03, Dmitry Potapov <dpotapov@gmail.com> wrote:\n>> On Fri, Apr 6, 2012 at 5:36 PM, demerphq <demerphq@gmail.com> wrote:\n>>> On 6 April 2012 13:38, Dmitry Potapov <dpotapov@gmail.com> wrote:\n>>>> Seriously, why do you care about beginners who use a centralized workflow\n>>>> and not beginners who have to use with existing projects that use more or\n>>>> less distributed workflow,\n>>>\n>>> Because the former are unlikely to be self-selected users of git and\n>>> instead are likely to be forced to use git because their $work has\n>>> dictated it to be so.\n>>\n>> Any decision is made by people. On its own, $work does not dictate what\n>> VCS or what workflow should be used. There are many ways for those who\n>> are in charge to screw up things. And a centralized workflow is not very\n>> scalable and many bad practices associated with it. While it is not easy\n>> to to convert a CVS/SVN repository to git that alone does not bring most\n>> of git advantages, because those advantages come from the workflow.\n>\n> Pretty well every project that uses git has a \"canonical upstream\n> repository\". Including for instance this one. Which basically means at\n> some point there is a centralized master repo. It is either owned by\n> someone like Linus or Junio, or it is owned by a company. Companies\n> tend to like to know that their valuable data is properly backed up,\n> and etc. This basically means central repos are inevitable. And git\n> works just fine like that thank you very much.\n\nIt seems you confuse a centralized workflow with existence of an official\n(central) repository. It is not same...\n\nDmitry\n"},{"id":"188723","messageId":"4F7FF19B.1060407@alum.mit.edu","threadId":"30086","inReplyTo":"20120406080004.GA27940@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-04-07T07:49:47Z","receivedAt":"2012-04-07T07:49:47Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"The very subject of this email is leading the discussion in circles.\n\nNeither current nor upstream is safe for beginners because there are \ndistinct workflows that require different behaviors in scenarios that \ngit cannot distinguish.\n\nOn 04/06/2012 10:00 AM, Jeff King wrote:\n> On Fri, Apr 06, 2012 at 09:44:48AM +0200, Matthieu Moy wrote:\n> [...]\n>> About safety, I don't think we can tell in general which bad push is the\n>> most serious. push.default=current may create branches unexpectedly,\n>> while push.default=upstream would ask you to \"push --set-upstream\" when\n>> creating the remote branch. push.default=upstream may push to the master\n>> when you wanted to create a remote topic branch. My feeling is that both\n>> are equally bad, but maybe I'm wrong here.\n\nExactly.  Choosing between \"current vs upstream\" is a false dichotomy.\n\nLet's create a new \"push.default\" option (call it \"beginner\" for the \nsake of discussion) that is intended for use *only* for people who \nhaven't explicitly chosen another alternative.  Let the \"beginner\" \noption do the obvious thing when it is uncontroversial and undangerous, \nand let it output a beginner-level help message in any scenarios where \nthe right thing to do is not obvious.  The help message should basically \nrecommend that the user run \"git config push.default VALUE\" and explain \nthe meaning of the possible VALUEs.\n\nIf \"push.default\" is not set, then have it default to \"beginner\" mode.\n\n> On the other hand, one thing we have not talked about is how one gets\n> into the \"topic push fast-forwards master\" situation. Which is running:\n>\n>    $ git checkout -b topic origin/master\n>\n> I'm not sure if that is something totally clueless people will run. And\n> maybe by the time people are intermediate enough git users to run that,\n> they will have figured out how upstream works. So maybe my concern is\n> overblown.\n\nWhen the \"beginner\" option is active, this case should trigger the \ninformational help message because git cannot know for sure what the \nuser wants.\n\n > I consider the much more likely scenarios for a new user to\n> be:\n>\n>    $ git clone ...&&  cd project\n>    $ hack hack hack\n>    $ git push\n>\n> which will work with either \"current\" or \"upstream\", or:\n>\n>    $ git clone ...&&  cd project\n>    $ git checkout foo ;# equivalent of \"git checkout -b foo origin/foo\"\n>    $ hack hack hack\n>    $ git push\n>\n> which also works with both\n\nSince the first two scenarios are uncontroversial, the \"beginner\" option \nshould do the expected thing.\n\n > or:\n>\n>    $ git clone ...&&  cd project\n>    $ git checkout -b topic\n>    $ hack hack hack\n>    $ git push\n>\n> which will error out for \"upstream\", and create a new branch \"topic\" on\n> the remote with \"current\".\n\nThe correct behavior in the above scenario depends on the workflow, so \nthe \"beginner\" option should not do anything except supply help information.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"188724","messageId":"20120407075150.GA18168@sigill.intra.peff.net","threadId":"30086","inReplyTo":"4F7FF19B.1060407@alum.mit.edu","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-07T07:51:50Z","receivedAt":"2012-04-07T07:51:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Apr 07, 2012 at 09:49:47AM +0200, Michael Haggerty wrote:\n\n> Exactly.  Choosing between \"current vs upstream\" is a false dichotomy.\n> \n> Let's create a new \"push.default\" option (call it \"beginner\" for the\n> sake of discussion) that is intended for use *only* for people who\n> haven't explicitly chosen another alternative.  Let the \"beginner\"\n> option do the obvious thing when it is uncontroversial and\n> undangerous, and let it output a beginner-level help message in any\n> scenarios where the right thing to do is not obvious.  The help\n> message should basically recommend that the user run \"git config\n> push.default VALUE\" and explain the meaning of the possible VALUEs.\n> \n> If \"push.default\" is not set, then have it default to \"beginner\" mode.\n\nI would be fine with that (I've suggested it elsewhere in the thread,\nthough I think I stole the idea originally from you. Speaking of going\nin circles. :) ).\n\n-Peff\n"},{"id":"188726","messageId":"4F7FFD7A.80104@pileofstuff.org","threadId":"30086","inReplyTo":"20120407075150.GA18168@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-04-07T08:40:26Z","receivedAt":"2012-04-07T08:40:26Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On a slight aside, should we add @{downstream} to describe the opposite\nof @{upstream}?  Seeing that around the place would give intermediate\nusers a clue about why pull and push aren't as related as they think,\nand would be useful here and there in code (e.g. __git_ps1 could show a\nbetter bash prompt with GIT_PS1_SHOWUPSTREAM).\n\n\t- Andrew\n"},{"id":"188757","messageId":"7viphaygsg.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120407075150.GA18168@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-08T04:43:43Z","receivedAt":"2012-04-08T04:43:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sat, Apr 07, 2012 at 09:49:47AM +0200, Michael Haggerty wrote:\n> ...\n>> If \"push.default\" is not set, then have it default to \"beginner\" mode.\n>\n> I would be fine with that (I've suggested it elsewhere in the thread,\n> though I think I stole the idea originally from you. Speaking of going\n> in circles. :) ).\n\nThis makes the first priority for 1.7.10 cycle to come up with a solid\nimplementation of the \"beginner\" mode, I guess.\n"},{"id":"188776","messageId":"CAMP44s2p-pRq9E34M8KA009mcfv8572O87DCNw_w2At7r+OF_g@mail.gmail.com","threadId":"30086","inReplyTo":"20120330071358.GB30656@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-04-08T12:52:52Z","receivedAt":"2012-04-08T12:52:52Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nI only now read this thread (or most of it).\n\nFirst of all, personally I never do 'git push' because I'm never sure\nof what it would do, and instead of trying to figure it out, I just\nspecify the branches/tags I want to push.\n\nI've seen a lot of people vote for 'upstream', and while I think\nthat's an improvement, I saw very good arguments against it; namely;\nthe fact that the configured upstream might not be the right one, and\nthat it would be confusing to new users. Hell, I almost never know\nwhat is the upstream branch of the branch I am currently on, so I\nthink 'current' makes more sense.\n\nHowever, another good argument is that switching away from matching\nwould break the symmetry with 'git pull', while it has been argued\nthey are not really symmetric anyway, it would be nice if they were.\nWhich brings me to how I personally use 'git pull'; I never use it in\nany shape or form, and the reason is similar to why I don't do 'git\npush'; I don't know what it's going to do.\n\nI think it's important to consider what people have been suggesting\nnew users, and one common suggestion has been to change the\n'push.default' configuration right away, so it most definitely needs\nto be changed, but another common suggestion is to avoid 'git pull'\ncompletely.\n\nPersonally I think that if 'push.default' was 'current', I might use\n'git push' without arguments more often, as I would know *exactly*\nwhat's going to happen, and it's very often what I want. But also, it\nwould be great if 'git pull' without arguments did something\nsymmetrically similar; only pull a branch with the same name. In\naddition to that, a lot of people end up doing merges by mistake,\nbecause they use 'git pull' assuming it would do the same as in other\nSCMs, so it would be great if 'git pull' would do --rebase by default,\nand use the remote/current branch as the base for the rebase instead.\nThis is more or less what I always end up doing manually anyway (git\nfetch origin; git rebase -i origin/master).\n\nWhile the 'git pull' changes are a separate topic, I wanted to mention\nthem as a rationale as to why I think 'push.default' should be\n'current'.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"188921","messageId":"20120411020816.GU376@gmail.com","threadId":"30086","inReplyTo":"20120406071520.GD25301@sigill.intra.peff.net","subject":"[RFC/PATCH] Give better 'pull' advice when pushing non-ff updates to current branch","fromName":"Christopher Tiwald","fromEmail":"christiwald@gmail.com","sentAt":"2012-04-11T02:08:16Z","receivedAt":"2012-04-11T02:08:16Z","isPatch":true,"sender":{"key":"christiwald@gmail.com","avatar":"https://avatars.githubusercontent.com/u/667276?v=4"},"body":"On Fri, Apr 06, 2012 at 03:15:20AM -0400, Jeff King wrote:\n> So shouldn't the advice for a non-fast-forward push be:\n> \n>    if $source_ref is currently checked out\n>            advise \"git checkout $source_ref, and then...\"\n>    fi\n>    if $dest_remote == branch.$source_ref.remote &&\n>       $dest_ref == branch.$source_ref.merge\n>            advise \"git pull\"\n>    else\n>            advise \"git pull $dest_remote $dest_ref\"\n>    fi\n> \n> That handles only one ref, of course. If you get multiple non-ff\n> failures, I'm not sure what we should advise.\n\nHmmm. Maybe something like this? Note to reviewers: This is necessarily\nbased on ct/advise-push-default.\n\nAssuming this logic is sound and the patch is a reasonable change, I'm not\nwedded to \"pushNonFFCurrentUntracked\" and \"pushNonFFCurrentTracked\". I'm\nconcerned both config options are a bit too long. Is there a better, more\nconcise way to specify those config options?\n\n---- >8 ----\nSuppose a user configured a local branch to track an upstream branch by\na different name or didn't set an upstream branch at all. In these\ncases, issuing 'git pull' without specifying a remote repository or\nrefspec can be dangerous. In the first case, 'git pull --rebase' could\nrewrite published history. In the second, 'git pull' without argument\nwill fail.\n\nModify 'git push's non-fast-forward advice to account for these cases.\nInstruct users who push a non-fast-forward update to their current\nbranch to 'git pull <repository> <refspec>' when the branch is untracked\nor tracks to a different repo or refspec then the one they specified.\nOtherwise, instruct users to 'git pull'. Make both types of advice\nconfigurable, so that users who disable one won't disable the other on\naccident. Finally, offer users who configure a branch for octopus\nmerges, i.e. where 'branch->merge_nr > 1', the simple 'git pull' advice.\n\nSigned-off-by: Christopher Tiwald <christiwald@gmail.com>\n---\n Documentation/config.txt |    9 +++++++--\n advice.c                 |    6 ++++--\n advice.h                 |    3 ++-\n builtin/push.c           |   48 +++++++++++++++++++++++++++++++++++++++++-----\n 4 files changed, 56 insertions(+), 10 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex fb386ab..fd72120 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -141,9 +141,14 @@ advice.*::\n \t\tSet this variable to 'false' if you want to disable\n \t\t'pushNonFFCurrent', 'pushNonFFDefault', and\n \t\t'pushNonFFMatching' simultaneously.\n-\tpushNonFFCurrent::\n+\tpushNonFFCurrentUntracked::\n \t\tAdvice shown when linkgit:git-push[1] fails due to a\n-\t\tnon-fast-forward update to the current branch.\n+\t\tnon-fast-forward update to the current branch and that\n+\t\tbranch doesn't match the tracked remote and refspec.\n+\tpushNonFFCurrentTracked::\n+\t\tAdvice shown when linkgit:git-push[1] fails due to a\n+\t\tnon-fast-forward update to the current branch and that\n+\t\tbranch matches the tracked remote and refspec.\n \tpushNonFFDefault::\n \t\tAdvice to set 'push.default' to 'upstream' or 'current'\n \t\twhen you ran linkgit:git-push[1] and pushed 'matching\ndiff --git a/advice.c b/advice.c\nindex a492eea..828a41b 100644\n--- a/advice.c\n+++ b/advice.c\n@@ -1,7 +1,8 @@\n #include \"cache.h\"\n \n int advice_push_nonfastforward = 1;\n-int advice_push_non_ff_current = 1;\n+int advice_push_non_ff_current_untracked = 1;\n+int advice_push_non_ff_current_tracked = 1;\n int advice_push_non_ff_default = 1;\n int advice_push_non_ff_matching = 1;\n int advice_status_hints = 1;\n@@ -15,7 +16,8 @@ static struct {\n \tint *preference;\n } advice_config[] = {\n \t{ \"pushnonfastforward\", &advice_push_nonfastforward },\n-\t{ \"pushnonffcurrent\", &advice_push_non_ff_current },\n+\t{ \"pushnonffcurrentuntracked\", &advice_push_non_ff_current_untracked },\n+\t{ \"pushnonffcurrenttracked\", &advice_push_non_ff_current_tracked },\n \t{ \"pushnonffdefault\", &advice_push_non_ff_default },\n \t{ \"pushnonffmatching\", &advice_push_non_ff_matching },\n \t{ \"statushints\", &advice_status_hints },\ndiff --git a/advice.h b/advice.h\nindex f3cdbbf..c18809f 100644\n--- a/advice.h\n+++ b/advice.h\n@@ -4,7 +4,8 @@\n #include \"git-compat-util.h\"\n \n extern int advice_push_nonfastforward;\n-extern int advice_push_non_ff_current;\n+extern int advice_push_non_ff_current_untracked;\n+extern int advice_push_non_ff_current_tracked;\n extern int advice_push_non_ff_default;\n extern int advice_push_non_ff_matching;\n extern int advice_status_hints;\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 8a14e4b..0671d27 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -118,12 +118,18 @@ static void setup_default_push_refspecs(struct remote *remote)\n \t}\n }\n \n-static const char message_advice_pull_before_push[] =\n+static const char message_advice_tracked_pull_before_push[] =\n \tN_(\"Updates were rejected because the tip of your current branch is behind\\n\"\n \t   \"its remote counterpart. Merge the remote changes (e.g. 'git pull')\\n\"\n \t   \"before pushing again.\\n\"\n \t   \"See the 'Note about fast-forwards' in 'git push --help' for details.\");\n \n+static const char message_advice_untracked_pull_before_push[] =\n+\tN_(\"Updates were rejected because the tip of your current branch is behind\\n\"\n+\t   \"its remote counterpart. Merge the remote changes to your local branch\\n\"\n+\t   \"(e.g. 'git pull <repository> <refspec>') before pushing again.\\n\"\n+\t   \"See the 'Note about fast-forwards' in 'git push --help' for details.\");\n+\n static const char message_advice_use_upstream[] =\n \tN_(\"Updates were rejected because a pushed branch tip is behind its remote\\n\"\n \t   \"counterpart. If you did not intend to push that branch, you may want to\\n\"\n@@ -136,11 +142,20 @@ static const char message_advice_checkout_pull_push[] =\n \t   \"(e.g. 'git pull') before pushing again.\\n\"\n \t   \"See the 'Note about fast-forwards' in 'git push --help' for details.\");\n \n-static void advise_pull_before_push(void)\n+static void advise_tracked_pull_before_push(void)\n+{\n+\tif (!advice_push_non_ff_current_tracked ||\n+\t    !advice_push_nonfastforward)\n+\t\treturn;\n+\tadvise(_(message_advice_tracked_pull_before_push));\n+}\n+\n+static void advise_untracked_pull_before_push(void)\n {\n-\tif (!advice_push_non_ff_current || !advice_push_nonfastforward)\n+\tif (!advice_push_non_ff_current_untracked ||\n+\t    !advice_push_nonfastforward)\n \t\treturn;\n-\tadvise(_(message_advice_pull_before_push));\n+\tadvise(_(message_advice_untracked_pull_before_push));\n }\n \n static void advise_use_upstream(void)\n@@ -161,6 +176,16 @@ static int push_with_options(struct transport *transport, int flags)\n {\n \tint err;\n \tint nonfastforward;\n+\tstruct branch *branch;\n+\tstruct strbuf buf = STRBUF_INIT;\n+\n+\tbranch = branch_get(NULL);\n+\n+\tif (branch) {\n+\t\tstrbuf_addstr(&buf, transport->remote->name);\n+\t\tstrbuf_addstr(&buf, \"/\");\n+\t\tstrbuf_addstr(&buf, branch->name);\n+\t}\n \n \ttransport_set_verbosity(transport, verbosity, progress);\n \n@@ -185,7 +210,18 @@ static int push_with_options(struct transport *transport, int flags)\n \tdefault:\n \t\tbreak;\n \tcase NON_FF_HEAD:\n-\t\tadvise_pull_before_push();\n+\t\t/* Branches configured for octopus merges should advise\n+\t\t * just 'git pull' */\n+\t\tif (branch->remote_name &&\n+\t\t    branch->merge &&\n+\t\t    branch->merge_nr == 1 &&\n+\t\t    !strcmp(transport->remote->name, branch->remote_name) &&\n+\t\t    !strcmp(strbuf_detach(&buf, NULL),\n+\t\t\t    prettify_refname(branch->merge[0]->dst))) {\n+\t\t\tadvise_tracked_pull_before_push();\n+\t\t}\n+\t\telse\n+\t\t\tadvise_untracked_pull_before_push();\n \t\tbreak;\n \tcase NON_FF_OTHER:\n \t\tif (default_matching_used)\n@@ -195,6 +231,8 @@ static int push_with_options(struct transport *transport, int flags)\n \t\tbreak;\n \t}\n \n+\tstrbuf_release(&buf);\n+\n \treturn 1;\n }\n \n-- \n1.7.10.4.g2c970.dirty\n"},{"id":"188978","messageId":"vpq62d6dyzr.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"7viphaygsg.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-11T16:17:28Z","receivedAt":"2012-04-11T16:17:28Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jeff King <peff@peff.net> writes:\n>\n>> On Sat, Apr 07, 2012 at 09:49:47AM +0200, Michael Haggerty wrote:\n>> ...\n>>> If \"push.default\" is not set, then have it default to \"beginner\" mode.\n>>\n>> I would be fine with that (I've suggested it elsewhere in the thread,\n>> though I think I stole the idea originally from you. Speaking of going\n>> in circles. :) ).\n>\n> This makes the first priority for 1.7.10 cycle to come up with a solid\n> implementation of the \"beginner\" mode, I guess.\n\nI guess so. I found the idea relevant the first time it came in the\ndiscussion, and I'm starting to get really convinced that this is the\nway to go. And if we're wrong, it will be much easier to migrate to\neither \"current\" or \"upstream\" later.\n\nNo time to code this right now, but I may come up with a patch in a few\ndays. Any idea on the real name? I'd call it \"safeUpstream\" or\n\"safeCurrent\", but that's probably by lack of a better name.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"188988","messageId":"7vpqbemd5k.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"vpq62d6dyzr.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-11T16:44:23Z","receivedAt":"2012-04-11T16:44:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Jeff King <peff@peff.net> writes:\n>>\n>>> On Sat, Apr 07, 2012 at 09:49:47AM +0200, Michael Haggerty wrote:\n>>> ...\n>>>> If \"push.default\" is not set, then have it default to \"beginner\" mode.\n>>>\n>>> I would be fine with that (I've suggested it elsewhere in the thread,\n>>> though I think I stole the idea originally from you. Speaking of going\n>>> in circles. :) ).\n>>\n>> This makes the first priority for 1.7.10 cycle to come up with a solid\n>> implementation of the \"beginner\" mode, I guess.\n>\n> I guess so. I found the idea relevant the first time it came in the\n> discussion, and I'm starting to get really convinced that this is the\n> way to go. And if we're wrong, it will be much easier to migrate to\n> either \"current\" or \"upstream\" later.\n>\n> No time to code this right now, but I may come up with a patch in a few\n> days. Any idea on the real name? I'd call it \"safeUpstream\" or\n> \"safeCurrent\", but that's probably by lack of a better name.\n\nI'd say \"simple\" ;-)\n"},{"id":"189083","messageId":"20120412071150.GB31122@sigill.intra.peff.net","threadId":"30086","inReplyTo":"4F7FFD7A.80104@pileofstuff.org","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-12T07:11:51Z","receivedAt":"2012-04-12T07:11:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Apr 07, 2012 at 09:40:26AM +0100, Andrew Sayers wrote:\n\n> On a slight aside, should we add @{downstream} to describe the opposite\n> of @{upstream}?  Seeing that around the place would give intermediate\n> users a clue about why pull and push aren't as related as they think,\n> and would be useful here and there in code (e.g. __git_ps1 could show a\n> better bash prompt with GIT_PS1_SHOWUPSTREAM).\n\nMaybe. I don't really see how it is useful, but maybe you want to flesh\nour your proposal with some examples? I do not use __git_ps1, so I'm not\nsure what you want to improve there.\n\n-Peff\n"},{"id":"189087","messageId":"20120412075535.GC31122@sigill.intra.peff.net","threadId":"30086","inReplyTo":"vpq62d6dyzr.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-12T07:55:35Z","receivedAt":"2012-04-12T07:55:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 11, 2012 at 06:17:28PM +0200, Matthieu Moy wrote:\n\n> > This makes the first priority for 1.7.10 cycle to come up with a solid\n> > implementation of the \"beginner\" mode, I guess.\n> \n> I guess so. I found the idea relevant the first time it came in the\n> discussion, and I'm starting to get really convinced that this is the\n> way to go. And if we're wrong, it will be much easier to migrate to\n> either \"current\" or \"upstream\" later.\n> \n> No time to code this right now, but I may come up with a patch in a few\n> days. Any idea on the real name? I'd call it \"safeUpstream\" or\n> \"safeCurrent\", but that's probably by lack of a better name.\n\nI think it is as simple as applying the usual upstream rules, then\nchecking the remote name against the local name. Like this:\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex b6c0fee..6077ecc 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -75,7 +75,7 @@ static int push_url_of_remote(struct remote *remote, const char ***url_p)\n \treturn remote->url_nr;\n }\n \n-static void setup_push_upstream(struct remote *remote)\n+static void setup_push_upstream(struct remote *remote, int simple)\n {\n \tstruct strbuf refspec = STRBUF_INIT;\n \tstruct branch *branch = branch_get(NULL);\n@@ -103,6 +103,29 @@ static void setup_push_upstream(struct remote *remote)\n \t\t      \"to update which remote branch.\"),\n \t\t    remote->name, branch->name);\n \n+\tif (simple && strcmp(branch->refname, branch->merge[0]->src)) {\n+\t\t/*\n+\t\t * There's no point in using shorten_unambiguous_ref here,\n+\t\t * as the ambiguity would be on the remote side, not what\n+\t\t * we have locally. Plus, this is supposed to be the simple\n+\t\t * mode. If the user is doing something crazy like setting\n+\t\t * upstream to a non-branch, we should probably be showing\n+\t\t * them the big ugly fully qualified ref.\n+\t\t */\n+\t\tconst char *short_up = skip_prefix(branch->merge[0]->src, \"refs/heads/\");\n+\t\tdie(_(\"The upstream branch of your current branch does not match\\n\"\n+\t\t      \"the name of your current branch.  To push to the upstream branch\\n\"\n+\t\t      \"on the remote, use\\n\"\n+\t\t      \"\\n\"\n+\t\t      \"    git push %s HEAD:%s\\n\"\n+\t\t      \"\\n\"\n+\t\t      \"To push to the branch of the same name on the remote, use\\n\"\n+\t\t      \"\\n\"\n+\t\t      \"    git push %s %s\\n\"),\n+\t\t    remote->name, short_up ? short_up : branch->merge[0]->src,\n+\t\t    remote->name, branch->name);\n+\t}\n+\n \tstrbuf_addf(&refspec, \"%s:%s\", branch->name, branch->merge[0]->src);\n \tadd_refspec(refspec.buf);\n }\n@@ -115,8 +138,12 @@ static void setup_default_push_refspecs(struct remote *remote)\n \t\tadd_refspec(\":\");\n \t\tbreak;\n \n+\tcase PUSH_DEFAULT_SIMPLE:\n+\t\tsetup_push_upstream(remote, 1);\n+\t\tbreak;\n+\n \tcase PUSH_DEFAULT_UPSTREAM:\n-\t\tsetup_push_upstream(remote);\n+\t\tsetup_push_upstream(remote, 0);\n \t\tbreak;\n \n \tcase PUSH_DEFAULT_CURRENT:\ndiff --git a/cache.h b/cache.h\nindex e12b15f..0f862dd 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -624,6 +624,7 @@ enum rebase_setup_type {\n enum push_default_type {\n \tPUSH_DEFAULT_NOTHING = 0,\n \tPUSH_DEFAULT_MATCHING,\n+\tPUSH_DEFAULT_SIMPLE,\n \tPUSH_DEFAULT_UPSTREAM,\n \tPUSH_DEFAULT_CURRENT\n };\ndiff --git a/config.c b/config.c\nindex ad03908..0ca0a6f 100644\n--- a/config.c\n+++ b/config.c\n@@ -824,6 +824,8 @@ static int git_default_push_config(const char *var, const char *value)\n \t\t\tpush_default = PUSH_DEFAULT_NOTHING;\n \t\telse if (!strcmp(value, \"matching\"))\n \t\t\tpush_default = PUSH_DEFAULT_MATCHING;\n+\t\telse if (!strcmp(value, \"simple\"))\n+\t\t\tpush_default = PUSH_DEFAULT_SIMPLE;\n \t\telse if (!strcmp(value, \"upstream\"))\n \t\t\tpush_default = PUSH_DEFAULT_UPSTREAM;\n \t\telse if (!strcmp(value, \"tracking\")) /* deprecated */\ndiff --git a/environment.c b/environment.c\nindex c93b8f4..1defcd4 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -52,7 +52,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;\n enum rebase_setup_type autorebase = AUTOREBASE_NEVER;\n-enum push_default_type push_default = PUSH_DEFAULT_MATCHING;\n+enum push_default_type push_default = PUSH_DEFAULT_SIMPLE;\n #ifndef OBJECT_CREATION_MODE\n #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS\n #endif\n"},{"id":"189089","messageId":"vpqhawp2wxs.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"20120412075535.GC31122@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-12T08:09:35Z","receivedAt":"2012-04-12T08:09:35Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> I think it is as simple as applying the usual upstream rules, then\n> checking the remote name against the local name. Like this:\n\nThis fails if no upstream is configured. I think applying \"current\"\ninstead of failing in this case makes perfect sense (i.e. \"simple\"\nshould fail only if there is an upstream configured, and it has a\ndifferent name).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189090","messageId":"20120412081407.GE31122@sigill.intra.peff.net","threadId":"30086","inReplyTo":"vpqhawp2wxs.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-12T08:14:07Z","receivedAt":"2012-04-12T08:14:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 12, 2012 at 10:09:35AM +0200, Matthieu Moy wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > I think it is as simple as applying the usual upstream rules, then\n> > checking the remote name against the local name. Like this:\n> \n> This fails if no upstream is configured. I think applying \"current\"\n> instead of failing in this case makes perfect sense (i.e. \"simple\"\n> should fail only if there is an upstream configured, and it has a\n> different name).\n\nThen the rule is not really \"act only if upstream and current would do\nthe same thing\".\n\nOn the one hand, I think what you are suggesting is reasonable in most\ncases. On the other hand, what if the lack of upstream is because the\nuser failed to configure it properly? Then it could be surprising.\n\nI don't have a strong opinion either way. Do you want to pick up my\npatch and start tweaking?\n\n-Peff\n"},{"id":"189093","messageId":"vpqfwc9wckl.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"20120412081407.GE31122@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-12T08:59:06Z","receivedAt":"2012-04-12T08:59:06Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> Then the rule is not really \"act only if upstream and current would do\n> the same thing\".\n\nRight. That would be closer to \"fail with explicit error when where to\npush is not clear enough\".\n\n> On the one hand, I think what you are suggesting is reasonable in most\n> cases. On the other hand, what if the lack of upstream is because the\n> user failed to configure it properly? Then it could be surprising.\n>\n> I don't have a strong opinion either way.\n\nNo strong opinion either, but I wanted to raise the point to make sure\nwe agree.\n\nWith your patch, \"git push\" fails with\n\n  fatal: The current branch branch-name has no upstream branch.\n  To push the current branch and set the remote as upstream, use\n  \n      git push --set-upstream origin branch-name\n\nso it's not really bad: the suggestion guides the user to a situation\nwhere the next \"git push\" will succeed unambiguously. As a side effect,\nthe next \"git pull\" will fetch from the same branch, which is probably\nwhat the user wants if he hasn't explicitely configured an upstream\nbranch yet.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189105","messageId":"7viph5gfet.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20120412071150.GB31122@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-12T15:04:26Z","receivedAt":"2012-04-12T15:04:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sat, Apr 07, 2012 at 09:40:26AM +0100, Andrew Sayers wrote:\n>\n>> On a slight aside, should we add @{downstream} to describe the opposite\n>> of @{upstream}?  Seeing that around the place would give intermediate\n>> users a clue about why pull and push aren't as related as they think,\n>> and would be useful here and there in code (e.g. __git_ps1 could show a\n>> better bash prompt with GIT_PS1_SHOWUPSTREAM).\n>\n> Maybe. I don't really see how it is useful, but maybe you want to flesh\n> our your proposal with some examples? I do not use __git_ps1, so I'm not\n> sure what you want to improve there.\n\nI took \"downstream\" as an opposite of \"upstream\".\n\nThe \"upstream\" of your branch is often (but not always) a remote tracking\nbranch, and because it makes sense to only have zero or one (but not more)\nbranch.$name.merge, \"$name@{upstream}\" would mean something.  There is an\nN-to-1 mapping from branches to their upstreams.\n\nGiven a remote tracking branch $name, (or if you use \"upstream\" to fork\nyour branch off of another of your branches, it could be a local branch),\nthere can be many branches that call it an \"upstream\", which means that\nthe notation \"$name@{downstream}\" cannot even map to a single object name\nor a refname; it is a 1-to-N mapping.\n\nSo I thought this was a joke and not a serious proposal.\n"},{"id":"189113","messageId":"7vpqbdeyfh.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"vpqfwc9wckl.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-12T15:56:34Z","receivedAt":"2012-04-12T15:56:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Jeff King <peff@peff.net> writes:\n>\n>> Then the rule is not really \"act only if upstream and current would do\n>> the same thing\".\n>\n> Right. That would be closer to \"fail with explicit error when where to\n> push is not clear enough\".\n\nI think that is a good explanation.\n\n>> On the one hand, I think what you are suggesting is reasonable in most\n>> cases. On the other hand, what if the lack of upstream is because the\n>> user failed to configure it properly? Then it could be surprising.\n>>\n>> I don't have a strong opinion either way.\n>\n> No strong opinion either, but I wanted to raise the point to make sure\n> we agree.\n>\n> With your patch, \"git push\" fails with\n>\n>   fatal: The current branch branch-name has no upstream branch.\n>   To push the current branch and set the remote as upstream, use\n>   \n>       git push --set-upstream origin branch-name\n>\n> so it's not really bad: the suggestion guides the user to a situation\n> where the next \"git push\" will succeed unambiguously. As a side effect,\n> the next \"git pull\" will fetch from the same branch, which is probably\n> what the user wants if he hasn't explicitely configured an upstream\n> branch yet.\n\nSounds sensible.\n"},{"id":"189146","messageId":"4F874639.5090207@pileofstuff.org","threadId":"30086","inReplyTo":"20120412071150.GB31122@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-04-12T21:16:41Z","receivedAt":"2012-04-12T21:16:41Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 12/04/12 08:11, Jeff King wrote:\n> On Sat, Apr 07, 2012 at 09:40:26AM +0100, Andrew Sayers wrote:\n> \n>> On a slight aside, should we add @{downstream} to describe the opposite\n>> of @{upstream}?  Seeing that around the place would give intermediate\n>> users a clue about why pull and push aren't as related as they think,\n>> and would be useful here and there in code (e.g. __git_ps1 could show a\n>> better bash prompt with GIT_PS1_SHOWUPSTREAM).\n> \n> Maybe. I don't really see how it is useful, but maybe you want to flesh\n> our your proposal with some examples? I do not use __git_ps1, so I'm not\n> sure what you want to improve there.\n\nThis discussion has highlighted the fact that a lot of people (myself\nincluded) had difficulty with the idea that push and pull could be\nasymmetrical operations.  Speaking for myself,\npush/pull/upstream/downstream/etc. has always been one of those things\nin my peripheral vision that worked well enough that I never really\nthought about it.  I think this is a fairly important bug in the\ndocumentation, which I guess didn't come across when I suggested a\nsolution that was mostly about code.\n\nI could be wrong, but looking over this discussion suggests to me a\npattern where people who actually thought about this stuff understood it\npretty quickly, whereas those of us who hadn't previously thought about\nit had to unlearn the vague notion that \"upstream\" was somehow both the\nplace you push to and the place you pull from, despite being\nincompatible with the meaning of the word.\n\nI described this before as being \"in my peripheral vision\", which is as\ndifferent from being in central vision (like it is for you guys) as it\nis different from being out of vision altogether (like it is for new\npeople).  Peripheral processing is a notoriously troubled route for\nideas, because people tend to pick up on cues and internalise them in\nirrational ways without noticing.  A classic version control example is\nhow nobody ever said \"commits are expensive and should be used\ncautiously\", but everyone just sort of came to that conclusion without\nreally thinking about it.  As soon as DVCSs forced us to actually focus\non the problem and think about it rationally, it became obvious that we\nneeded to unlearn the vague assumption and go with a model that made\nmore sense.\n\nI'm pretty sure the cue I internalised to make me think \"push\" and\n\"pull\" were symmetrical was that the word \"upstream\" gets thrown around\na lot in the documentation, whereas nobody ever uses the word\n\"downstream\".  Having heard \"upstream this\" and \"upstream that\" every\ntime I opened a man page, the word \"upstream\" just naturally popped into\nmy head when I wondered where `git push` went.  Just to be clear - I'm\nnot arguing that anybody that consciously asked themselves the question\n\"where does `git push` go?\" would rationally conclude the answer is\n\"upstream\", I'm saying that those of us who never really thought about\nit had a mental process bubbling away deep in some murky bit of our\nbrain which plugged the gap in our understanding with the only word it knew.\n\nSo if the problem is that the documentation cues the reader to think\nabout upstreams but not to think about downstreams, the solution is to\nfind excuses to talk more about downstreams.  As far as I'm concerned\n@{upstream} means \"the place that commits come from when I `git pull`\",\nso it makes perfect sense to me that @{downstream} would mean \"the place\ncommits go to when I `git push`\".  That would let us write documentation\nlike the following:\n\n    Git has been optimised to make branching and merging very easy.\n    Most git workflows involve using an upstream branch (that you pull\n    other people's work from), your current branch (that you commit\n    your changes to) and a downstream branch (that you push the\n    combined work to).  To understand the this a bit better, try using\n    these commands:\n\n    git log # commits in your local repository\n    git log @{upstream} # commits in your upstream branch\n    git log @{downstream} # commits in your downstream branch\n    git log HEAD..@{upstream} # commits you haven't pulled yet\n    git log @{downstream}..HEAD # commits you haven't pushed yet\n\n    A lot of workflows simplify the process by assuming that your\n    upstream is also your downstream, and that both exist in some\n    shared repository, but as far as git's concerned this is just one\n    special case.\n\nI realise the above is a bit simplistic and would need to be written\nbetter, but hopefully it demonstrates how code support for \"downstream\"\nterminology would let us write documentation that provides better cues\nabout how the whole process works.\n\nI mentioned __git_ps1 before as an example of where @{downstream} would\nbe useful in code.  The idea is that you can set your prompt to include\ne.g. \"+3-2\" if you have 3 commits to push and 2 commits to pull, which\nprobably tells you lies right now when your push target happens not to\nbe the same as your upstream.\n\n\t- Andrew\n"},{"id":"189148","messageId":"7vlim04ou1.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"4F874639.5090207@pileofstuff.org","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-12T21:33:58Z","receivedAt":"2012-04-12T21:33:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Sayers <andrew-git@pileofstuff.org> writes:\n\n> So if the problem is that the documentation cues the reader to think\n> about upstreams but not to think about downstreams, the solution is to\n> find excuses to talk more about downstreams.  As far as I'm concerned\n> @{upstream} means \"the place that commits come from when I `git pull`\",\n> so it makes perfect sense to me that @{downstream} would mean \"the place\n> commits go to when I `git push`\".\n\nIn a separate message I completely misunderstood what you meant by\n\"downstream\".\n\nIf you had something like this:\n\n\t[remote \"origin\"]\n        \turl = ...\n        [remote \"destination\"]\n                pushURL = ...\n\n\t[branch \"topic\"]\n        \tremote = origin\n                merge = refs/heads/master\n\t\tpushRemote = destination # new\n                push = refs/heads/topic # new\n\nyou could express that asymmetric layout in a natural way.  When you say\n\"git push\" while on your \"topic\" branch, it will go to \"destination\"\nremote to update their \"topic\" branch.\n\nInteresting...\n"},{"id":"189151","messageId":"20120412221110.GA22426@sigill.intra.peff.net","threadId":"30086","inReplyTo":"7vlim04ou1.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-12T22:11:10Z","receivedAt":"2012-04-12T22:11:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 12, 2012 at 02:33:58PM -0700, Junio C Hamano wrote:\n\n> Andrew Sayers <andrew-git@pileofstuff.org> writes:\n> \n> > So if the problem is that the documentation cues the reader to think\n> > about upstreams but not to think about downstreams, the solution is to\n> > find excuses to talk more about downstreams.  As far as I'm concerned\n> > @{upstream} means \"the place that commits come from when I `git pull`\",\n> > so it makes perfect sense to me that @{downstream} would mean \"the place\n> > commits go to when I `git push`\".\n> \n> In a separate message I completely misunderstood what you meant by\n> \"downstream\".\n\nYeah, I also took it to mean that the \"downstream\" of your \"upstream\"\nwould be where you started (though as you mentioned, it is not 1-to-1,\nso that would not work anyway).\n\nBut this:\n\n> If you had something like this:\n> \n> \t[remote \"origin\"]\n>         \turl = ...\n>         [remote \"destination\"]\n>                 pushURL = ...\n> \n> \t[branch \"topic\"]\n>         \tremote = origin\n>                 merge = refs/heads/master\n> \t\tpushRemote = destination # new\n>                 push = refs/heads/topic # new\n> \n> you could express that asymmetric layout in a natural way.  When you say\n> \"git push\" while on your \"topic\" branch, it will go to \"destination\"\n> remote to update their \"topic\" branch.\n\nis much more useful (and I already complained about the lack of\nsomething like pushRemote recently). I just think it should not be\ncalled \"downstream\", as it is not the reverse of upstream.\n\n-Peff\n"},{"id":"189158","messageId":"A13E3113738743C6B002BB6B076E1FEE@PhilipOakley","threadId":"30086","inReplyTo":"20120412221110.GA22426@sigill.intra.peff.net","subject":"Re: push.default: current vs upstream","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-04-12T22:59:58Z","receivedAt":"2012-04-12T22:59:58Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jeff King\" <peff@peff.net> Sent: Thursday, April 12, 2012 11:11 PM\n> On Thu, Apr 12, 2012 at 02:33:58PM -0700, Junio C Hamano wrote:\n>\n>> Andrew Sayers <andrew-git@pileofstuff.org> writes:\n>>\n>> > So if the problem is that the documentation cues the reader to think\n>> > about upstreams but not to think about downstreams, the solution is to\n>> > find excuses to talk more about downstreams.  As far as I'm concerned\n>> > @{upstream} means \"the place that commits come from when I `git pull`\",\n>> > so it makes perfect sense to me that @{downstream} would mean \"the\n>> > place\n>> > commits go to when I `git push`\".\n\n>> In a separate message I completely misunderstood what you meant by\n>> \"downstream\".\n>\n\nIt would be useful to have \"upstream\" and \"downstream\" clarified in the \ndocumentation, say the Workflows man pages or some suitable place. Upstream \nis used often but isn't well defined (no obvious link anyway) - it's more of \nconcept than a place (hence Andrew's option), while downstream is hardly \nmentioned at all.\n\nFor the push.default option can I suggest a different approach focused on\nthe beginner? If both current and upstream are potentially problematic, then\nsurely the default initially should be unset, so that a beginner's push is\nrefused with a pleasant message, e.g.\n\"  git push.default is unset,\n   please use 'git push <remote> <branch>', or see its man page;\n  or set the push.default to match your work style.\"\n\nThis offers the beginner a cause, an immediate solution, and guidance for\nthe long term. I deliberately called it a work style rather than workflow.\n\nOne work style for push.default could be \"beginner\" which would reduce the\nmessage to:\n-  git push.default is unset, use 'git push <remote> <branch>'\n\nThis gives the beginner time to learn their workflow, and gives a friendly \nversion of the command.\n\nWhile the expert user's regression would be to select _their_\ncurrent/upstream work style.\n\nThis approach does take the opposite route to most of the default settings\nas it is about stopping beginners making major mistakes, rather than helping\nthem become productive.\n\nOne issue I had with the 'git push' man page is that 'refspec's are a fairly \nadvanced (at least intermediate) concept that would confuse the beginner who \nis still getting to grips with their branches and remotes, so using the 'git \npush <remote> <branch>' version [*1*] will be friendlier to those beginners.\n\nPhilip\n\n> Yeah, I also took it to mean that the \"downstream\" of your \"upstream\"\n> would be where you started (though as you mentioned, it is not 1-to-1,\n> so that would not work anyway).\n>\n> But this:\n>\n>> If you had something like this:\n>>\n>> [remote \"origin\"]\n>>         url = ...\n>>         [remote \"destination\"]\n>>                 pushURL = ...\n>>\n>> [branch \"topic\"]\n>>         remote = origin\n>>                 merge = refs/heads/master\n>> pushRemote = destination # new\n>>                 push = refs/heads/topic # new\n>>\n>> you could express that asymmetric layout in a natural way.  When you say\n>> \"git push\" while on your \"topic\" branch, it will go to \"destination\"\n>> remote to update their \"topic\" branch.\n>\n> is much more useful (and I already complained about the lack of\n> something like pushRemote recently). I just think it should not be\n> called \"downstream\", as it is not the reverse of upstream.\n>\n> -Peff\n> --\n[1] http://gitready.com/beginner/2009/01/21/pushing-and-pulling.html \n"},{"id":"189209","messageId":"7vmx6f2ztd.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"A13E3113738743C6B002BB6B076E1FEE@PhilipOakley","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-13T19:31:58Z","receivedAt":"2012-04-13T19:31:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" <philipoakley@iee.org> writes:\n\n> From: \"Jeff King\" <peff@peff.net> Sent: Thursday, April 12, 2012 11:11 PM\n>> On Thu, Apr 12, 2012 at 02:33:58PM -0700, Junio C Hamano wrote:\n>>\n>>> Andrew Sayers <andrew-git@pileofstuff.org> writes:\n>>>\n>>> > So if the problem is that the documentation cues the reader to think\n>>> > about upstreams but not to think about downstreams, the solution is to\n>>> > find excuses to talk more about downstreams.  As far as I'm concerned\n>>> > @{upstream} means \"the place that commits come from when I `git pull`\",\n>>> > so it makes perfect sense to me that @{downstream} would mean \"the\n>>> > place\n>>> > commits go to when I `git push`\".\n>\n>>> In a separate message I completely misunderstood what you meant by\n>>> \"downstream\".\n>\n> It would be useful to have \"upstream\" and \"downstream\" clarified in\n> the documentation, say the Workflows man pages or some suitable\n> place.\n\nPerhaps, but I am not convinced.  I am not convinced that it is a bad idea\neither, so I'll think aloud for several paragraphs, and probably will not\nreach a conclusion in this message. Just a food for thought...\n\nI think the word \"downstream\" has rarely been used in the context of Git,\nbut because it is a natural opposite for the word \"upstream\", I've seen it\nused when people talk about others who fork from them, e.g. Linus can call\nhis lieutenants his downstream.\n\nThe word \"upstream\" almost always refers to \"the place the updates from\nothers come to me from\".  Linus is the upstream for his lieutenants---the\nlieutenants pull from Linus.  In the shared repository \"everybody pulls\nfrom there to get updates from others, and everybody pushes there to\npropagate their own work to others\" setting, the shared repository is the\nupstream for the project participants---again, they pull from there.\n\nNotice however that the word \"upstream\" is meaningless for the integrator\nwith the above definition of the word.  \"The place the updates from others\ncome to Linus from\" ought to be his \"upstream\", but the workflow does not\ngo like so. Linus does not have a fixed \"upstream\" he pulls from before\nhe starts his day. For that matter, the lieutenants are not supposed to\npull from Linus every day before they start their work, either, but when\nthey need to synchronize with the upstream, they pull from Linus, so in\nthat sense, the word \"upstream\" means something to them.\n\nI suspect that using the word \"downstream\" to mean \"the place the result\nof my work is pushed to\" will only add to the confusion.\n\nIn a distributed \"kernel-like\" workflow, the lieutenants obviously do not\npush to Linus's repository. If we raise the level of discussion to talk\nabout the flows of data, ignoring the difference of mechanism used\n(i.e. \"push\" vs \"format-patch | send-email\"), the work by lieutenants is\nstill fed back to their \"upstream\".  They \"upstream\" (verb) the result of\ntheir work.\n\nPerhaps it was a mistake to use the word \"upstream\" in a shared repository\nworkflow, which invites the confusing word \"downstream\". In that context,\nthere is not really an \"up\" vs \"down\" relationship.  \"shared\" vs \"mine\"\nrelationship is all that exists in that context.\n"},{"id":"189561","messageId":"4F8DCF06.5010505@pileofstuff.org","threadId":"30086","inReplyTo":"7vlim04ou1.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-04-17T20:13:58Z","receivedAt":"2012-04-17T20:13:58Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 12/04/12 22:33, Junio C Hamano wrote:\n> Andrew Sayers <andrew-git@pileofstuff.org> writes:\n> \n>> So if the problem is that the documentation cues the reader to think\n>> about upstreams but not to think about downstreams, the solution is to\n>> find excuses to talk more about downstreams.  As far as I'm concerned\n>> @{upstream} means \"the place that commits come from when I `git pull`\",\n>> so it makes perfect sense to me that @{downstream} would mean \"the place\n>> commits go to when I `git push`\".\n> \n> In a separate message I completely misunderstood what you meant by\n> \"downstream\".\n> \n> If you had something like this:\n> \n> \t[remote \"origin\"]\n>         \turl = ...\n>         [remote \"destination\"]\n>                 pushURL = ...\n> \n> \t[branch \"topic\"]\n>         \tremote = origin\n>                 merge = refs/heads/master\n> \t\tpushRemote = destination # new\n>                 push = refs/heads/topic # new\n> \n> you could express that asymmetric layout in a natural way.  When you say\n> \"git push\" while on your \"topic\" branch, it will go to \"destination\"\n> remote to update their \"topic\" branch.\n> \n> Interesting...\n> \n\nIf \"upstream\" and \"downstream\" are ambiguous, it makes sense to avoid\nthe words altogether - you can't reduce ambiguity by adding more\ndefinitions.  I'm replying to the above instead of your most recent\nmessage because it might provide a fresh angle on the problem.\n\nWe already have language to describe \"upstream\" unambiguously, and an\nintuitive way of describing the opposite of it, so specifying revisions\nwith the same language would help tie some things together and make git\neasier to learn.  The only problem  is that we currently use two words\ninstead of one.\n\nWe could talk about @{remote}/@{pushRemote}, which I'd expect to be\nintuitive to a beginner despite the inaccuracy - we already talk about\n\"remote repositories\" and \"remote tracking branches\", so @{remote} would\nbe easy to guess.  Alternatively, @{merge}/@{push} would a bit more\naccurate but a bit less obvious to people that don't really understand\nmerging yet (or are figuring out merge vs. rebase).  Or we could make up\nsome similar-but-distinct terms like @{mergeSource} and @{pushSink} that\nreinforce the language above without overlapping.\n\n\t- Andrew\n"},{"id":"189718","messageId":"xmqqzka7so2p.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"7vpqbdeyfh.fsf@alter.siamese.dyndns.org","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-19T16:06:54Z","receivedAt":"2012-04-19T16:06:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>\n>> Jeff King <peff@peff.net> writes:\n>> ...\n>>> I don't have a strong opinion either way.\n>>\n>> No strong opinion either, but I wanted to raise the point to make sure\n>> we agree.\n>>\n>> With your patch, \"git push\" fails with\n>>\n>>   fatal: The current branch branch-name has no upstream branch.\n>>   To push the current branch and set the remote as upstream, use\n>>   \n>>       git push --set-upstream origin branch-name\n>>\n>> so it's not really bad: the suggestion guides the user to a situation\n>> where the next \"git push\" will succeed unambiguously. As a side effect,\n>> the next \"git pull\" will fetch from the same branch, which is probably\n>> what the user wants if he hasn't explicitely configured an upstream\n>> branch yet.\n>\n> Sounds sensible.\n\nSo what happened to this discussion?  Does anybody want to roll the \"simple\"\ndefault based on Peff's patch?\n"},{"id":"189726","messageId":"vpqaa27bgon.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"xmqqzka7so2p.fsf@junio.mtv.corp.google.com","subject":"Re: push.default: current vs upstream","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-19T20:38:32Z","receivedAt":"2012-04-19T20:38:32Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> So what happened to this discussion?  \n\nI've been busy, so did nothing, and my procrastination didn't pay ;-).\n\n> Does anybody want to roll the \"simple\" default based on Peff's patch?\n\nI was about to, actually. I'll go for Peff's semantics at least for now,\nand just add tests.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189728","messageId":"xmqqd373v3is.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"vpqaa27bgon.fsf@bauges.imag.fr","subject":"Re: push.default: current vs upstream","fromName":"Junio C Hamano","fromEmail":"jch@google.com","sentAt":"2012-04-19T21:02:35Z","receivedAt":"2012-04-19T21:02:35Z","isPatch":false,"sender":{"key":"jch@google.com","avatar":null},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> So what happened to this discussion?  \n>\n> I've been busy, so did nothing, and my procrastination didn't pay ;-).\n\nHeh, it rarely pays to procrastinate when it is clear that you are the\nparty who cares the most deeply about the issue among the ones capable\nof changing the status quo.\n\nAs long as it is not forgotten, that is fine, and being busy is good ;-)\n\n>> Does anybody want to roll the \"simple\" default based on Peff's patch?\n>\n> I was about to, actually. I'll go for Peff's semantics at least for now,\n> and just add tests.\n\nThanks.\n"},{"id":"189731","messageId":"1334876234-20077-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"vpqaa27bgon.fsf@bauges.imag.fr","subject":"[RFC/PATCH 0/3] push.default upcomming change","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-19T22:57:11Z","receivedAt":"2012-04-19T22:57:11Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"So, here's my first re-roll of Peff's patch. I've included the warning\nchange in the same patch serie because topics are related and to avoid\nconflicts.\n\nCompared to Peff's version, I've added testcases, but the 'simple'\nmode still lacks doc (I will do soon).\n\nClemens Buchacher (1):\n  t5570: use explicit push refspec\n\nMatthieu Moy (2):\n  push: introduce new push.default mode \"simple\"\n  push: start warning upcoming default change for push.default\n\n builtin/push.c        |   72 +++++++++++++++++++++++++++++++++++++++++++++++--\n cache.h               |    4 ++-\n config.c              |    4 ++-\n environment.c         |    2 +-\n t/t5516-fetch-push.sh |   33 +++++++++++++++++++++++\n t/t5570-git-daemon.sh |   30 ++++++++++-----------\n 6 files changed, 124 insertions(+), 21 deletions(-)\n\n-- \n1.7.10.140.g8c333\n"},{"id":"189732","messageId":"1334876234-20077-2-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1334876234-20077-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 1/3] push: introduce new push.default mode \"simple\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-19T22:57:12Z","receivedAt":"2012-04-19T22:57:12Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"When calling \"git push\" without argument, we want to allow Git to do\nsomething simple to explain and safe. push.default=matching is unsafe\nwhen use to push to shared repositories, and hard to explain to beginners\nin some context. It is debatable whether 'upstream' or 'current' is the\nsafest or the easiest to explain, so introduce a new mode called 'simple'\nthat is the intersection of them: push the upstream branch, but only if\nit has the same name remotely. If not, give an error that suggest the\nright command to push explicitely to 'upstream' or 'current'.\n\nA question is whether to allow pushing when no upstream is configured. An\nargument in favor of allowing the push is that it makes the new mode work\nin more cases. On the other hand, refusing to push when no upstream is\nconfigured encourages the user to set the upstream, which will be\nbeneficial on the next pull. Lacking better argument, we chose to deny\nthe push, because it will be easier to change in the future is someone\nshows us wrong.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n builtin/push.c        |   47 +++++++++++++++++++++++++++++++++++++++++++++--\n cache.h               |    1 +\n config.c              |    4 +++-\n t/t5516-fetch-push.sh |   33 +++++++++++++++++++++++++++++++++\n 4 files changed, 82 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex d315475..4602cd8 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -65,7 +65,17 @@ static void set_refspecs(const char **refs, int nr)\n \t}\n }\n \n-static void setup_push_upstream(struct remote *remote)\n+static int push_url_of_remote(struct remote *remote, const char ***url_p)\n+{\n+\tif (remote->pushurl_nr) {\n+\t\t*url_p = remote->pushurl;\n+\t\treturn remote->pushurl_nr;\n+\t}\n+\t*url_p = remote->url;\n+\treturn remote->url_nr;\n+}\n+\n+static void setup_push_upstream(struct remote *remote, int simple)\n {\n \tstruct strbuf refspec = STRBUF_INIT;\n \tstruct branch *branch = branch_get(NULL);\n@@ -87,6 +97,35 @@ static void setup_push_upstream(struct remote *remote)\n \tif (branch->merge_nr != 1)\n \t\tdie(_(\"The current branch %s has multiple upstream branches, \"\n \t\t    \"refusing to push.\"), branch->name);\n+\tif (strcmp(branch->remote_name, remote->name))\n+\t\tdie(_(\"You are pushing to remote '%s', which is not the upstream of\\n\"\n+\t\t      \"your current branch '%s', without telling me what to push\\n\"\n+\t\t      \"to update which remote branch.\"),\n+\t\t    remote->name, branch->name);\n+\n+\tif (simple && strcmp(branch->refname, branch->merge[0]->src)) {\n+\t\t/*\n+\t\t * There's no point in using shorten_unambiguous_ref here,\n+\t\t * as the ambiguity would be on the remote side, not what\n+\t\t * we have locally. Plus, this is supposed to be the simple\n+\t\t * mode. If the user is doing something crazy like setting\n+\t\t * upstream to a non-branch, we should probably be showing\n+\t\t * them the big ugly fully qualified ref.\n+\t\t */\n+\t\tconst char *short_up = skip_prefix(branch->merge[0]->src, \"refs/heads/\");\n+\t\tdie(_(\"The upstream branch of your current branch does not match\\n\"\n+\t\t      \"the name of your current branch.  To push to the upstream branch\\n\"\n+\t\t      \"on the remote, use\\n\"\n+\t\t      \"\\n\"\n+\t\t      \"    git push %s HEAD:%s\\n\"\n+\t\t      \"\\n\"\n+\t\t      \"To push to the branch of the same name on the remote, use\\n\"\n+\t\t      \"\\n\"\n+\t\t      \"    git push %s %s\\n\"),\n+\t\t    remote->name, short_up ? short_up : branch->merge[0]->src,\n+\t\t    remote->name, branch->name);\n+\t}\n+\n \tstrbuf_addf(&refspec, \"%s:%s\", branch->name, branch->merge[0]->src);\n \tadd_refspec(refspec.buf);\n }\n@@ -99,8 +138,12 @@ static void setup_default_push_refspecs(struct remote *remote)\n \t\tadd_refspec(\":\");\n \t\tbreak;\n \n+\tcase PUSH_DEFAULT_SIMPLE:\n+\t\tsetup_push_upstream(remote, 1);\n+\t\tbreak;\n+\n \tcase PUSH_DEFAULT_UPSTREAM:\n-\t\tsetup_push_upstream(remote);\n+\t\tsetup_push_upstream(remote, 0);\n \t\tbreak;\n \n \tcase PUSH_DEFAULT_CURRENT:\ndiff --git a/cache.h b/cache.h\nindex 806bf2b..f1c1bb8 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -624,6 +624,7 @@ enum rebase_setup_type {\n enum push_default_type {\n \tPUSH_DEFAULT_NOTHING = 0,\n \tPUSH_DEFAULT_MATCHING,\n+\tPUSH_DEFAULT_SIMPLE,\n \tPUSH_DEFAULT_UPSTREAM,\n \tPUSH_DEFAULT_CURRENT\n };\ndiff --git a/config.c b/config.c\nindex 68d3294..024bc74 100644\n--- a/config.c\n+++ b/config.c\n@@ -829,6 +829,8 @@ static int git_default_push_config(const char *var, const char *value)\n \t\t\tpush_default = PUSH_DEFAULT_NOTHING;\n \t\telse if (!strcmp(value, \"matching\"))\n \t\t\tpush_default = PUSH_DEFAULT_MATCHING;\n+\t\telse if (!strcmp(value, \"simple\"))\n+\t\t\tpush_default = PUSH_DEFAULT_SIMPLE;\n \t\telse if (!strcmp(value, \"upstream\"))\n \t\t\tpush_default = PUSH_DEFAULT_UPSTREAM;\n \t\telse if (!strcmp(value, \"tracking\")) /* deprecated */\n@@ -837,7 +839,7 @@ static int git_default_push_config(const char *var, const char *value)\n \t\t\tpush_default = PUSH_DEFAULT_CURRENT;\n \t\telse {\n \t\t\terror(\"Malformed value for %s: %s\", var, value);\n-\t\t\treturn error(\"Must be one of nothing, matching, \"\n+\t\t\treturn error(\"Must be one of simple, nothing, matching, \"\n \t\t\t\t     \"tracking or current.\");\n \t\t}\n \t\treturn 0;\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex b5417cc..f4f9d06 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -497,6 +497,39 @@ test_expect_success 'push with config remote.*.push = HEAD' '\n \tcheck_push_result $the_first_commit heads/local\n '\n \n+test_expect_success 'push without argument (push.default)' '\n+\tmk_test heads/master &&\n+\n+\ttest_debug \"echo no remote branch\" &&\n+\tgit checkout $the_first_commit -b new-branch &&\n+\ttest_must_fail git -c push.default=simple push &&\n+\ttest_must_fail git -c push.default=matching push &&\n+\ttest_must_fail git -c push.default=upstream push &&\n+\n+\ttest_debug \"echo existing branch, no upstream configured\" &&\n+\tgit config branch.new-branch.remote there &&\n+\tgit -c push.default=current push &&\n+\tgit -c push.default=simple push &&\n+\tgit -c push.default=matching push &&\n+\tgit config --unset branch.new-branch.remote &&\n+\ttest_must_fail git -c push.default=simple push &&\n+\n+\ttest_debug \"echo upstream configured\" &&\n+\tgit push --set-upstream testrepo new-branch &&\n+\tgit -c push.default=simple push &&\n+\tcheck_push_result $the_first_commit heads/new-branch &&\n+\tgit config branch.new-branch.merge other-branch &&\n+\ttest_must_fail git -c push.default=simple push &&\n+\tgit -c push.default=upstream push &&\n+\tcheck_push_result $the_first_commit heads/other-branch &&\n+\tgit push --set-upstream there new-branch &&\n+\n+\ttest_debug \"echo advance local commit\" &&\n+\tgit merge $the_commit &&\n+\tgit -c push.default=simple push &&\n+\tcheck_push_result $the_commit heads/new-branch\n+'\n+\n # clean up the cruft left with the previous one\n git config --remove-section remote.there\n git config --remove-section branch.master\n-- \n1.7.10.140.g8c333\n"},{"id":"189734","messageId":"1334876234-20077-3-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1334876234-20077-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 2/3] t5570: use explicit push refspec","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-19T22:57:13Z","receivedAt":"2012-04-19T22:57:13Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"From: Clemens Buchacher <drizzd@aon.at>\n\nThe default mode for push without arguments will change. Some warnings\nare about to be enabled for such use, which causes some t5570 tests to\nfail because they do not expect this output.\n\nFix this by passing an explicit refspec to git push. To that end, change\nthe calling conventions of test_remote_error in order to accomodate\nextra command arguments.\n\nSigned-off-by: Clemens Buchacher <drizzd@aon.at>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n t/t5570-git-daemon.sh |   30 ++++++++++++++----------------\n 1 file changed, 14 insertions(+), 16 deletions(-)\n\ndiff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh\nindex 7cbc999..a3a4e47 100755\n--- a/t/t5570-git-daemon.sh\n+++ b/t/t5570-git-daemon.sh\n@@ -103,14 +103,12 @@ test_remote_error()\n \t\tesac\n \tdone\n \n-\tif test $# -ne 3\n-\tthen\n-\t\terror \"invalid number of arguments\"\n-\tfi\n-\n+\tmsg=$1\n+\tshift\n \tcmd=$1\n-\trepo=$2\n-\tmsg=$3\n+\tshift\n+\trepo=$1\n+\tshift || error \"invalid number of arguments\"\n \n \tif test -x \"$GIT_DAEMON_DOCUMENT_ROOT_PATH/$repo\"\n \tthen\n@@ -122,7 +120,7 @@ test_remote_error()\n \t\tfi\n \tfi\n \n-\ttest_must_fail git \"$cmd\" \"$GIT_DAEMON_URL/$repo\" 2>output &&\n+\ttest_must_fail git \"$cmd\" \"$GIT_DAEMON_URL/$repo\" \"$@\" 2>output &&\n \techo \"fatal: remote error: $msg: /$repo\" >expect &&\n \ttest_cmp expect output\n \tret=$?\n@@ -131,18 +129,18 @@ test_remote_error()\n }\n \n msg=\"access denied or repository not exported\"\n-test_expect_success 'clone non-existent' \"test_remote_error    clone nowhere.git '$msg'\"\n-test_expect_success 'push disabled'      \"test_remote_error    push  repo.git    '$msg'\"\n-test_expect_success 'read access denied' \"test_remote_error -x fetch repo.git    '$msg'\"\n-test_expect_success 'not exported'       \"test_remote_error -n fetch repo.git    '$msg'\"\n+test_expect_success 'clone non-existent' \"test_remote_error    '$msg' clone nowhere.git    \"\n+test_expect_success 'push disabled'      \"test_remote_error    '$msg' push  repo.git master\"\n+test_expect_success 'read access denied' \"test_remote_error -x '$msg' fetch repo.git       \"\n+test_expect_success 'not exported'       \"test_remote_error -n '$msg' fetch repo.git       \"\n \n stop_git_daemon\n start_git_daemon --informative-errors\n \n-test_expect_success 'clone non-existent' \"test_remote_error    clone nowhere.git 'no such repository'\"\n-test_expect_success 'push disabled'      \"test_remote_error    push  repo.git    'service not enabled'\"\n-test_expect_success 'read access denied' \"test_remote_error -x fetch repo.git    'no such repository'\"\n-test_expect_success 'not exported'       \"test_remote_error -n fetch repo.git    'repository not exported'\"\n+test_expect_success 'clone non-existent' \"test_remote_error    'no such repository'      clone nowhere.git    \"\n+test_expect_success 'push disabled'      \"test_remote_error    'service not enabled'     push  repo.git master\"\n+test_expect_success 'read access denied' \"test_remote_error -x 'no such repository'      fetch repo.git       \"\n+test_expect_success 'not exported'       \"test_remote_error -n 'repository not exported' fetch repo.git       \"\n \n stop_git_daemon\n test_done\n-- \n1.7.10.140.g8c333\n"},{"id":"189733","messageId":"1334876234-20077-4-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1334876234-20077-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 3/3] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-19T22:57:14Z","receivedAt":"2012-04-19T22:57:14Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"In preparation for flipping the default to the \"simple\" mode from\nthe \"matching\" mode that is the historical default, start warning\nusers when they rely on unconfigured \"git push\" to default to the\n\"matching\" mode.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n builtin/push.c |   25 +++++++++++++++++++++++++\n cache.h        |    3 ++-\n environment.c  |    2 +-\n 3 files changed, 28 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 4602cd8..3bb8ce7 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -130,10 +130,35 @@ static void setup_push_upstream(struct remote *remote, int simple)\n \tadd_refspec(refspec.buf);\n }\n \n+static char warn_unspecified_push_default_msg[] =\n+N_(\"push.default is unset; its implicit value is changing in\\n\"\n+   \"Git 2.0 from 'matching' to 'simple'. To squelch this message\\n\"\n+   \"and maintain the current behavior after the default changes, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default matching\\n\"\n+   \"\\n\"\n+   \"To squelch this message and adopt the new behavior now, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default simple\\n\"\n+   \"\\n\"\n+   \"See 'git help config' and search for 'push.default' for further information.\");\n+\n+static void warn_unspecified_push_default_configuration(void)\n+{\n+\tstatic int warn_once;\n+\n+\tif (warn_once++)\n+\t\treturn;\n+\twarning(\"%s\\n\", _(warn_unspecified_push_default_msg));\n+}\n+\n static void setup_default_push_refspecs(struct remote *remote)\n {\n \tswitch (push_default) {\n \tdefault:\n+\tcase PUSH_DEFAULT_UNSPECIFIED:\n+\t\twarn_unspecified_push_default_configuration();\n+\t\t/* fallthru */\n \tcase PUSH_DEFAULT_MATCHING:\n \t\tadd_refspec(\":\");\n \t\tbreak;\ndiff --git a/cache.h b/cache.h\nindex f1c1bb8..851a673 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -626,7 +626,8 @@ enum push_default_type {\n \tPUSH_DEFAULT_MATCHING,\n \tPUSH_DEFAULT_SIMPLE,\n \tPUSH_DEFAULT_UPSTREAM,\n-\tPUSH_DEFAULT_CURRENT\n+\tPUSH_DEFAULT_CURRENT,\n+\tPUSH_DEFAULT_UNSPECIFIED\n };\n \n extern enum branch_track git_branch_track;\ndiff --git a/environment.c b/environment.c\nindex c93b8f4..d7e6c65 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -52,7 +52,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;\n enum rebase_setup_type autorebase = AUTOREBASE_NEVER;\n-enum push_default_type push_default = PUSH_DEFAULT_MATCHING;\n+enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;\n #ifndef OBJECT_CREATION_MODE\n #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS\n #endif\n-- \n1.7.10.140.g8c333\n"},{"id":"189736","messageId":"20120419234609.GA6020@sigill.intra.peff.net","threadId":"30086","inReplyTo":"1334876234-20077-2-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 1/3] push: introduce new push.default mode \"simple\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-19T23:46:09Z","receivedAt":"2012-04-19T23:46:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 20, 2012 at 12:57:12AM +0200, Matthieu Moy wrote:\n\n> diff --git a/builtin/push.c b/builtin/push.c\n> index d315475..4602cd8 100644\n> --- a/builtin/push.c\n> +++ b/builtin/push.c\n> @@ -65,7 +65,17 @@ static void set_refspecs(const char **refs, int nr)\n>  \t}\n>  }\n>  \n> -static void setup_push_upstream(struct remote *remote)\n> +static int push_url_of_remote(struct remote *remote, const char ***url_p)\n> +{\n> +\tif (remote->pushurl_nr) {\n> +\t\t*url_p = remote->pushurl;\n> +\t\treturn remote->pushurl_nr;\n> +\t}\n> +\t*url_p = remote->url;\n> +\treturn remote->url_nr;\n> +}\n> +\n\nEh, what's this? This wasn't part of my patch. It was part of Junio's\npatch which mine was based on (and it provokes a \"defined but not used\"\nwarning when your patch is applied on top of master).\n\n> @@ -87,6 +97,35 @@ static void setup_push_upstream(struct remote *remote)\n>  \tif (branch->merge_nr != 1)\n>  \t\tdie(_(\"The current branch %s has multiple upstream branches, \"\n>  \t\t    \"refusing to push.\"), branch->name);\n> +\tif (strcmp(branch->remote_name, remote->name))\n> +\t\tdie(_(\"You are pushing to remote '%s', which is not the upstream of\\n\"\n> +\t\t      \"your current branch '%s', without telling me what to push\\n\"\n> +\t\t      \"to update which remote branch.\"),\n> +\t\t    remote->name, branch->name);\n\nAnd this was from Junio's patch, which is really a separate topic (that\n\"git push foo\" should not respect an upstream branch name when the\nupstream remote is not \"foo\").\n\nSo I think your rebase turned out a little funny. We probably want to\npull in Junio's patch from the tip of jc/push-upstream-sanity (135dade).\nThough even that can be pared down a little. The push_url_of_remote\nrefactoring was part of an early iteration and does not have to be part\nof the final version (though I think it is a fine refactoring on its\nown).\n\n> diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\n> index b5417cc..f4f9d06 100755\n> --- a/t/t5516-fetch-push.sh\n> +++ b/t/t5516-fetch-push.sh\n\n135dade creates a new t5528 for testing push.default settings, so tests\ncould go there.\n\n-Peff\n"},{"id":"189754","messageId":"vpqfwbye9re.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"20120419234609.GA6020@sigill.intra.peff.net","subject":"Re: [PATCH 1/3] push: introduce new push.default mode \"simple\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-20T14:52:05Z","receivedAt":"2012-04-20T14:52:05Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> Eh, what's this? This wasn't part of my patch. It was part of Junio's\n> patch which mine was based on (and it provokes a \"defined but not used\"\n> warning when your patch is applied on top of master).\n\nOops, it seems I did some weird conflict resolution applying and\nrebasing your patch, plus I sent the serie late in the evening ;-).\n\n> 135dade creates a new t5528 for testing push.default settings, so tests\n> could go there.\n\nExcellent. Next re-roll will be based on next to use it.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189755","messageId":"1334933944-13446-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"vpqfwbye9re.fsf@bauges.imag.fr","subject":"[PATCH 0/4 v2] push.default upcomming change","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-20T14:59:00Z","receivedAt":"2012-04-20T14:59:00Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"OK, so this v2 is not supposed to be a draft anymore. It has\ndocumentation (while I was there, I added PATCH 1/4 thas tries to\ndocument better the existing modes), and I removed the hunks that came\nhere after a broken merge resolution.\n\nThis is based on next, it at least requires 135dade that creates\nt5528.\n\nClemens Buchacher (1):\n  t5570: use explicit push refspec\n\nMatthieu Moy (3):\n  Documentation: explain push.default option a bit more\n  push: introduce new push.default mode \"simple\"\n  push: start warning upcoming default change for push.default\n\n Documentation/config.txt |   20 +++++++++++++--\n builtin/push.c           |   55 ++++++++++++++++++++++++++++++++++++++--\n cache.h                  |    1 +\n config.c                 |    4 ++-\n t/t5528-push-default.sh  |   63 +++++++++++++++++++++++++++++++++++++++++++---\n t/t5570-git-daemon.sh    |   30 +++++++++++-----------\n 6 files changed, 149 insertions(+), 24 deletions(-)\n\n-- \n1.7.10.140.g8c333\n"},{"id":"189759","messageId":"1334933944-13446-2-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1334933944-13446-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 1/4] Documentation: explain push.default option a bit more","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-20T14:59:01Z","receivedAt":"2012-04-20T14:59:01Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"The previous documentation was explaining _what_ the options were doing,\nbut were of little help explaining _why_ a user should set his default to\neither of the options.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n Documentation/config.txt |   15 +++++++++++++--\n 1 file changed, 13 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex fb386ab..368a770 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1682,10 +1682,21 @@ push.default::\n * `nothing` - do not push anything.\n * `matching` - push all matching branches.\n   All branches having the same name in both ends are considered to be\n-  matching. This is the default.\n-* `upstream` - push the current branch to its upstream branch.\n+  matching. This is well suited when pushing to a non-shared\n+  repository, but may give surprising results when used on a\n+  repository shared by multiple users, since locally stalled\n+  branches will attempt a non-fast forward push if other users\n+  updated the branch remotely. This is the default.\n+* `upstream` - push the current branch to its upstream branch. See\n+  \"branch.<name>.merge\" for how to configure the upstream branch. This\n+  makes `git push` and `git pull` symmetrical in the sense that `push`\n+  will update the same remote ref as the one which is merged by\n+  `git pull`.\n * `tracking` - deprecated synonym for `upstream`.\n * `current` - push the current branch to a branch of the same name.\n+  This option allows publishing a branch to a remote repository using\n+  the same naming convention locally and remotely, in a more\n+  conservative and safer way than `matching`.\n \n rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\n-- \n1.7.10.140.g8c333\n"},{"id":"189757","messageId":"1334933944-13446-3-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1334933944-13446-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 2/4] push: introduce new push.default mode \"simple\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-20T14:59:02Z","receivedAt":"2012-04-20T14:59:02Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"When calling \"git push\" without argument, we want to allow Git to do\nsomething simple to explain and safe. push.default=matching is unsafe\nwhen use to push to shared repositories, and hard to explain to beginners\nin some context. It is debatable whether 'upstream' or 'current' is the\nsafest or the easiest to explain, so introduce a new mode called 'simple'\nthat is the intersection of them: push the upstream branch, but only if\nit has the same name remotely. If not, give an error that suggest the\nright command to push explicitely to 'upstream' or 'current'.\n\nA question is whether to allow pushing when no upstream is configured. An\nargument in favor of allowing the push is that it makes the new mode work\nin more cases. On the other hand, refusing to push when no upstream is\nconfigured encourages the user to set the upstream, which will be\nbeneficial on the next pull. Lacking better argument, we chose to deny\nthe push, because it will be easier to change in the future is someone\nshows us wrong.\n\nOriginal-patch-by: Jeff King <peff@peff.net>\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\nExcept for the broken-ness, this adds the last line in the warning message:\n\n\"To chose either option permanently, read about push.default in git-config(1)\"\n\n Documentation/config.txt |    3 +++\n builtin/push.c           |   32 +++++++++++++++++++++--\n cache.h                  |    1 +\n config.c                 |    4 ++-\n t/t5528-push-default.sh  |   63 +++++++++++++++++++++++++++++++++++++++++++---\n 5 files changed, 97 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 368a770..05d1472 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1697,6 +1697,9 @@ push.default::\n   This option allows publishing a branch to a remote repository using\n   the same naming convention locally and remotely, in a more\n   conservative and safer way than `matching`.\n+* `simple` - like `upstream`, but refuses to push if the upstream\n+  branch's name is different from the local one. This is the safest\n+  option and is well-suited for beginners.\n \n rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 6936713..ba0d6a0 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -76,7 +76,7 @@ static int push_url_of_remote(struct remote *remote, const char ***url_p)\n \treturn remote->url_nr;\n }\n \n-static void setup_push_upstream(struct remote *remote)\n+static void setup_push_upstream(struct remote *remote, int simple)\n {\n \tstruct strbuf refspec = STRBUF_INIT;\n \tstruct branch *branch = branch_get(NULL);\n@@ -103,6 +103,30 @@ static void setup_push_upstream(struct remote *remote)\n \t\t      \"your current branch '%s', without telling me what to push\\n\"\n \t\t      \"to update which remote branch.\"),\n \t\t    remote->name, branch->name);\n+\tif (simple && strcmp(branch->refname, branch->merge[0]->src)) {\n+\t\t/*\n+\t\t * There's no point in using shorten_unambiguous_ref here,\n+\t\t * as the ambiguity would be on the remote side, not what\n+\t\t * we have locally. Plus, this is supposed to be the simple\n+\t\t * mode. If the user is doing something crazy like setting\n+\t\t * upstream to a non-branch, we should probably be showing\n+\t\t * them the big ugly fully qualified ref.\n+\t\t */\n+\t\tconst char *short_up = skip_prefix(branch->merge[0]->src, \"refs/heads/\");\n+\t\tdie(_(\"The upstream branch of your current branch does not match\\n\"\n+\t\t      \"the name of your current branch.  To push to the upstream branch\\n\"\n+\t\t      \"on the remote, use\\n\"\n+\t\t      \"\\n\"\n+\t\t      \"    git push %s HEAD:%s\\n\"\n+\t\t      \"\\n\"\n+\t\t      \"To push to the branch of the same name on the remote, use\\n\"\n+\t\t      \"\\n\"\n+\t\t      \"    git push %s %s\\n\"\n+\t\t      \"\\n\"\n+\t\t      \"To chose either option permanently, read about push.default in git-config(1)\\n\"),\n+\t\t    remote->name, short_up ? short_up : branch->merge[0]->src,\n+\t\t    remote->name, branch->name);\n+\t}\n \n \tstrbuf_addf(&refspec, \"%s:%s\", branch->name, branch->merge[0]->src);\n \tadd_refspec(refspec.buf);\n@@ -119,8 +143,12 @@ static void setup_default_push_refspecs(struct remote *remote)\n \t\tadd_refspec(\":\");\n \t\tbreak;\n \n+\tcase PUSH_DEFAULT_SIMPLE:\n+\t\tsetup_push_upstream(remote, 1);\n+\t\tbreak;\n+\n \tcase PUSH_DEFAULT_UPSTREAM:\n-\t\tsetup_push_upstream(remote);\n+\t\tsetup_push_upstream(remote, 0);\n \t\tbreak;\n \n \tcase PUSH_DEFAULT_CURRENT:\ndiff --git a/cache.h b/cache.h\nindex d8f6f1e..5e419a1 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -580,6 +580,7 @@ enum rebase_setup_type {\n enum push_default_type {\n \tPUSH_DEFAULT_NOTHING = 0,\n \tPUSH_DEFAULT_MATCHING,\n+\tPUSH_DEFAULT_SIMPLE,\n \tPUSH_DEFAULT_UPSTREAM,\n \tPUSH_DEFAULT_CURRENT,\n \tPUSH_DEFAULT_UNSPECIFIED\ndiff --git a/config.c b/config.c\nindex 68d3294..024bc74 100644\n--- a/config.c\n+++ b/config.c\n@@ -829,6 +829,8 @@ static int git_default_push_config(const char *var, const char *value)\n \t\t\tpush_default = PUSH_DEFAULT_NOTHING;\n \t\telse if (!strcmp(value, \"matching\"))\n \t\t\tpush_default = PUSH_DEFAULT_MATCHING;\n+\t\telse if (!strcmp(value, \"simple\"))\n+\t\t\tpush_default = PUSH_DEFAULT_SIMPLE;\n \t\telse if (!strcmp(value, \"upstream\"))\n \t\t\tpush_default = PUSH_DEFAULT_UPSTREAM;\n \t\telse if (!strcmp(value, \"tracking\")) /* deprecated */\n@@ -837,7 +839,7 @@ static int git_default_push_config(const char *var, const char *value)\n \t\t\tpush_default = PUSH_DEFAULT_CURRENT;\n \t\telse {\n \t\t\terror(\"Malformed value for %s: %s\", var, value);\n-\t\t\treturn error(\"Must be one of nothing, matching, \"\n+\t\t\treturn error(\"Must be one of simple, nothing, matching, \"\n \t\t\t\t     \"tracking or current.\");\n \t\t}\n \t\treturn 0;\ndiff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\nindex c334c51..949dbdf 100755\n--- a/t/t5528-push-default.sh\n+++ b/t/t5528-push-default.sh\n@@ -13,6 +13,22 @@ test_expect_success 'setup bare remotes' '\n \tgit push parent2 HEAD\n '\n \n+# $1 = local revision\n+# $2 = remote repository\n+# $3 = remote revision (tested to be equal to the local one)\n+check_pushed_commit () {\n+\tgit rev-parse \"$1\" > expect &&\n+\tgit --git-dir=\"$2\" rev-parse \"$3\" > actual &&\n+\ttest_cmp expect actual\n+}\n+\n+# $1 = push.default value\n+# $2 = expected target branch for the push\n+test_push_success () {\n+\tgit -c push.default=\"$1\" push &&\n+\tcheck_pushed_commit HEAD repo1 \"$2\"\n+}\n+\n test_expect_success '\"upstream\" pushes to configured upstream' '\n \tgit checkout master &&\n \ttest_config branch.master.remote parent1 &&\n@@ -20,9 +36,7 @@ test_expect_success '\"upstream\" pushes to configured upstream' '\n \ttest_config push.default upstream &&\n \ttest_commit two &&\n \tgit push &&\n-\techo two >expect &&\n-\tgit --git-dir=repo1 log -1 --format=%s foo >actual &&\n-\ttest_cmp expect actual\n+\tcheck_pushed_commit HEAD repo1 foo\n '\n \n test_expect_success '\"upstream\" does not push on unconfigured remote' '\n@@ -51,4 +65,47 @@ test_expect_success '\"upstream\" does not push when remotes do not match' '\n \ttest_must_fail git push parent2\n '\n \n+test_expect_success 'push from/to new branch with upstream, matching and simple' '\n+\tgit checkout -b new-branch &&\n+\ttest_must_fail git -c push.default=simple push &&\n+\ttest_must_fail git -c push.default=matching push &&\n+\ttest_must_fail git -c push.default=upstream push\n+'\n+\n+test_expect_success 'push from/to new branch with current creates remote branch' '\n+\ttest_config branch.new-branch.remote repo1 &&\n+\tgit checkout new-branch &&\n+\ttest_push_success current new-branch\n+'\n+\n+test_expect_success 'push to existing branch, with no upstream configured' '\n+\ttest_config branch.master.remote repo1 &&\n+\tgit checkout master &&\n+\ttest_must_fail git -c push.default=simple push &&\n+\ttest_must_fail git -c push.default=upstream push\n+'\n+\n+test_expect_success 'push to existing branch, upstream configured with same name' '\n+\ttest_config branch.master.remote repo1 &&\n+\ttest_config branch.master.merge refs/heads/master &&\n+\tgit checkout master &&\n+\ttest_commit six &&\n+\ttest_push_success upstream master &&\n+\ttest_commit seven &&\n+\ttest_push_success simple master &&\n+\tcheck_pushed_commit HEAD repo1 master\n+'\n+\n+test_expect_success 'push to existing branch, upstream configured with different name' '\n+\ttest_config branch.master.remote repo1 &&\n+\ttest_config branch.master.merge refs/heads/other-name &&\n+\tgit checkout master &&\n+\ttest_commit eight &&\n+\ttest_push_success upstream other-name &&\n+\ttest_commit nine &&\n+\ttest_must_fail git -c push.default=simple push &&\n+\ttest_push_success current master &&\n+\ttest_must_fail check_pushed_commit HEAD repo1 other-name\n+'\n+\n test_done\n-- \n1.7.10.140.g8c333\n"},{"id":"189758","messageId":"1334933944-13446-4-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1334933944-13446-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 3/4] t5570: use explicit push refspec","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-20T14:59:03Z","receivedAt":"2012-04-20T14:59:03Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"From: Clemens Buchacher <drizzd@aon.at>\n\nThe default mode for push without arguments will change. Some warnings\nare about to be enabled for such use, which causes some t5570 tests to\nfail because they do not expect this output.\n\nFix this by passing an explicit refspec to git push. To that end, change\nthe calling conventions of test_remote_error in order to accomodate\nextra command arguments.\n\nSigned-off-by: Clemens Buchacher <drizzd@aon.at>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n t/t5570-git-daemon.sh |   30 ++++++++++++++----------------\n 1 file changed, 14 insertions(+), 16 deletions(-)\n\ndiff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh\nindex 7cbc999..a3a4e47 100755\n--- a/t/t5570-git-daemon.sh\n+++ b/t/t5570-git-daemon.sh\n@@ -103,14 +103,12 @@ test_remote_error()\n \t\tesac\n \tdone\n \n-\tif test $# -ne 3\n-\tthen\n-\t\terror \"invalid number of arguments\"\n-\tfi\n-\n+\tmsg=$1\n+\tshift\n \tcmd=$1\n-\trepo=$2\n-\tmsg=$3\n+\tshift\n+\trepo=$1\n+\tshift || error \"invalid number of arguments\"\n \n \tif test -x \"$GIT_DAEMON_DOCUMENT_ROOT_PATH/$repo\"\n \tthen\n@@ -122,7 +120,7 @@ test_remote_error()\n \t\tfi\n \tfi\n \n-\ttest_must_fail git \"$cmd\" \"$GIT_DAEMON_URL/$repo\" 2>output &&\n+\ttest_must_fail git \"$cmd\" \"$GIT_DAEMON_URL/$repo\" \"$@\" 2>output &&\n \techo \"fatal: remote error: $msg: /$repo\" >expect &&\n \ttest_cmp expect output\n \tret=$?\n@@ -131,18 +129,18 @@ test_remote_error()\n }\n \n msg=\"access denied or repository not exported\"\n-test_expect_success 'clone non-existent' \"test_remote_error    clone nowhere.git '$msg'\"\n-test_expect_success 'push disabled'      \"test_remote_error    push  repo.git    '$msg'\"\n-test_expect_success 'read access denied' \"test_remote_error -x fetch repo.git    '$msg'\"\n-test_expect_success 'not exported'       \"test_remote_error -n fetch repo.git    '$msg'\"\n+test_expect_success 'clone non-existent' \"test_remote_error    '$msg' clone nowhere.git    \"\n+test_expect_success 'push disabled'      \"test_remote_error    '$msg' push  repo.git master\"\n+test_expect_success 'read access denied' \"test_remote_error -x '$msg' fetch repo.git       \"\n+test_expect_success 'not exported'       \"test_remote_error -n '$msg' fetch repo.git       \"\n \n stop_git_daemon\n start_git_daemon --informative-errors\n \n-test_expect_success 'clone non-existent' \"test_remote_error    clone nowhere.git 'no such repository'\"\n-test_expect_success 'push disabled'      \"test_remote_error    push  repo.git    'service not enabled'\"\n-test_expect_success 'read access denied' \"test_remote_error -x fetch repo.git    'no such repository'\"\n-test_expect_success 'not exported'       \"test_remote_error -n fetch repo.git    'repository not exported'\"\n+test_expect_success 'clone non-existent' \"test_remote_error    'no such repository'      clone nowhere.git    \"\n+test_expect_success 'push disabled'      \"test_remote_error    'service not enabled'     push  repo.git master\"\n+test_expect_success 'read access denied' \"test_remote_error -x 'no such repository'      fetch repo.git       \"\n+test_expect_success 'not exported'       \"test_remote_error -n 'repository not exported' fetch repo.git       \"\n \n stop_git_daemon\n test_done\n-- \n1.7.10.140.g8c333\n"},{"id":"189756","messageId":"1334933944-13446-5-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1334933944-13446-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 4/4] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-20T14:59:04Z","receivedAt":"2012-04-20T14:59:04Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"In preparation for flipping the default to the \"simple\" mode from\nthe \"matching\" mode that is the historical default, start warning\nusers when they rely on unconfigured \"git push\" to default to the\n\"matching\" mode.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\nI've documented the upcomming change in Documentation/config.txt in\naddition to the warning.\n\n Documentation/config.txt |    6 ++++--\n builtin/push.c           |   23 +++++++++++++++++++++++\n 2 files changed, 27 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 05d1472..bda3f47 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1686,7 +1686,8 @@ push.default::\n   repository, but may give surprising results when used on a\n   repository shared by multiple users, since locally stalled\n   branches will attempt a non-fast forward push if other users\n-  updated the branch remotely. This is the default.\n+  updated the branch remotely. This is currently the default, but Git\n+  2.0 will change the default to `simple`.\n * `upstream` - push the current branch to its upstream branch. See\n   \"branch.<name>.merge\" for how to configure the upstream branch. This\n   makes `git push` and `git pull` symmetrical in the sense that `push`\n@@ -1699,7 +1700,8 @@ push.default::\n   conservative and safer way than `matching`.\n * `simple` - like `upstream`, but refuses to push if the upstream\n   branch's name is different from the local one. This is the safest\n-  option and is well-suited for beginners.\n+  option and is well-suited for beginners. It will become the default\n+  in Git 2.0.\n \n rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\ndiff --git a/builtin/push.c b/builtin/push.c\nindex ba0d6a0..23cedf0 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -132,12 +132,35 @@ static void setup_push_upstream(struct remote *remote, int simple)\n \tadd_refspec(refspec.buf);\n }\n \n+static char warn_unspecified_push_default_msg[] =\n+N_(\"push.default is unset; its implicit value is changing in\\n\"\n+   \"Git 2.0 from 'matching' to 'simple'. To squelch this message\\n\"\n+   \"and maintain the current behavior after the default changes, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default matching\\n\"\n+   \"\\n\"\n+   \"To squelch this message and adopt the new behavior now, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default simple\\n\"\n+   \"\\n\"\n+   \"See 'git help config' and search for 'push.default' for further information.\");\n+\n+static void warn_unspecified_push_default_configuration(void)\n+{\n+\tstatic int warn_once;\n+\n+\tif (warn_once++)\n+\t\treturn;\n+\twarning(\"%s\\n\", _(warn_unspecified_push_default_msg));\n+}\n+\n static void setup_default_push_refspecs(struct remote *remote)\n {\n \tswitch (push_default) {\n \tdefault:\n \tcase PUSH_DEFAULT_UNSPECIFIED:\n \t\tdefault_matching_used = 1;\n+\t\twarn_unspecified_push_default_configuration();\n \t\t/* fallthru */\n \tcase PUSH_DEFAULT_MATCHING:\n \t\tadd_refspec(\":\");\n-- \n1.7.10.140.g8c333\n"},{"id":"189776","messageId":"20120420201357.GA13103@sigill.intra.peff.net","threadId":"30086","inReplyTo":"1334933944-13446-2-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 1/4] Documentation: explain push.default option a bit more","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-20T20:13:57Z","receivedAt":"2012-04-20T20:13:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 20, 2012 at 04:59:01PM +0200, Matthieu Moy wrote:\n\n> The previous documentation was explaining _what_ the options were doing,\n> but were of little help explaining _why_ a user should set his default to\n> either of the options.\n\nI think your explanations are a definite improvement.\n\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index fb386ab..368a770 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n>[...]\n>  * `tracking` - deprecated synonym for `upstream`.\n\nThis is not directly related to your patch, but maybe it is worth\nremoving this (from the documentation) for the sake of simplicity. We\nwill still support the synonym (it has only been deprecated for a year),\nbut new users don't need to see it in the already-large list of options.\n\n-Peff\n"},{"id":"189778","messageId":"20120420203324.GB13103@sigill.intra.peff.net","threadId":"30086","inReplyTo":"1334933944-13446-3-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 2/4] push: introduce new push.default mode \"simple\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-20T20:33:25Z","receivedAt":"2012-04-20T20:33:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 20, 2012 at 04:59:02PM +0200, Matthieu Moy wrote:\n\n> it has the same name remotely. If not, give an error that suggest the\n> right command to push explicitely to 'upstream' or 'current'.\n\ns/suggest/&s/\n\n> beneficial on the next pull. Lacking better argument, we chose to deny\n> the push, because it will be easier to change in the future is someone\n> shows us wrong.\n\ns/is/if/\n\n> Original-patch-by: Jeff King <peff@peff.net>\n> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n> ---\n> Except for the broken-ness, this adds the last line in the warning message:\n> \n> \"To chose either option permanently, read about push.default in git-config(1)\"\n\nI don't think that makes sense if I have set \"push.default\" to \"simple\"\nmyself. IOW, shouldn't that get added later, when it eventually becomes\nthe default (and then, only when it was chosen because it is the\ndefault, not because somebody explicitly said they wanted it)?\n\n> @@ -837,7 +839,7 @@ static int git_default_push_config(const char *var, const char *value)\n>  \t\t\tpush_default = PUSH_DEFAULT_CURRENT;\n>  \t\telse {\n>  \t\t\terror(\"Malformed value for %s: %s\", var, value);\n> -\t\t\treturn error(\"Must be one of nothing, matching, \"\n> +\t\t\treturn error(\"Must be one of simple, nothing, matching, \"\n>  \t\t\t\t     \"tracking or current.\");\n\nNot your fault, but should this be s/tracking/upstream/ in the context\nline?\n\n> diff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\n> index c334c51..949dbdf 100755\n> --- a/t/t5528-push-default.sh\n> +++ b/t/t5528-push-default.sh\n> @@ -13,6 +13,22 @@ test_expect_success 'setup bare remotes' '\n>  \tgit push parent2 HEAD\n>  '\n>  \n> +# $1 = local revision\n> +# $2 = remote repository\n> +# $3 = remote revision (tested to be equal to the local one)\n> +check_pushed_commit () {\n> +\tgit rev-parse \"$1\" > expect &&\n> +\tgit --git-dir=\"$2\" rev-parse \"$3\" > actual &&\n> +\ttest_cmp expect actual\n> +}\n\nThis is an extremely minor nit, but a test failure is often easier to\nread if you use \"log -1 --format=%s\" here, assuming that the commits are\ngiven reasonable subjects (so you get \"-two\\n+one\" or similar instead of\nsome commit ids which aren't meaningful).\n\nAlso, I notice you take a repo argument here, but then all of the\ncallers just pass \"repo1\" (and the test_push_success function hardcodes\nrepo1).\n\n> +test_expect_success 'push to existing branch, upstream configured with different name' '\n> +\ttest_config branch.master.remote repo1 &&\n> +\ttest_config branch.master.merge refs/heads/other-name &&\n> +\tgit checkout master &&\n> +\ttest_commit eight &&\n> +\ttest_push_success upstream other-name &&\n> +\ttest_commit nine &&\n> +\ttest_must_fail git -c push.default=simple push &&\n> +\ttest_push_success current master &&\n> +\ttest_must_fail check_pushed_commit HEAD repo1 other-name\n> +'\n\nIn the final must_fail, wouldn't it be more robust to use an affirmative\ncheck that it was not touched, instead of checking that we failed to\nfind it to be equal (which could fail for other, unrelated reasons)?\nLike this:\n\n  check_pushed_commit HEAD^ repo1 other-name\n\nI also wonder if it would make sense to wrap the whole \"failed push\"\nthing in a function like this:\n\n  test_push_failure() {\n          git --git-dir=repo1 log -1 --format=%s \"$2\" >expect &&\n          test_must_fail git -c push.default=\"$1\" &&\n          git --git-dir=repo1 log -1 --format=%s \"$2\" >actual &&\n          test_cmp expect actual\n  }\n\nand then the earlier failures could also get this extra double-check for\nfree (that push not only reported failure, but that it failed without\nactually touching the remote end, not for some unrelated reason).\n\nThat's all minor stuff; the bulk of the patch looks good to me.\n\n-Peff\n"},{"id":"189779","messageId":"20120420203552.GC13103@sigill.intra.peff.net","threadId":"30086","inReplyTo":"1334933944-13446-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 0/4 v2] push.default upcomming change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-04-20T20:35:52Z","receivedAt":"2012-04-20T20:35:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 20, 2012 at 04:59:00PM +0200, Matthieu Moy wrote:\n\n> OK, so this v2 is not supposed to be a draft anymore. It has\n> documentation (while I was there, I added PATCH 1/4 thas tries to\n> document better the existing modes), and I removed the hunks that came\n> here after a broken merge resolution.\n> \n> This is based on next, it at least requires 135dade that creates\n> t5528.\n\nYou are better off to just build it on 135dade in that case, as that is\nwhat Junio will apply it on (never directly on top of next). It\ngenerally isn't a problem, but there's no point reason not to do so.\n\n> Clemens Buchacher (1):\n>   t5570: use explicit push refspec\n> \n> Matthieu Moy (3):\n>   Documentation: explain push.default option a bit more\n>   push: introduce new push.default mode \"simple\"\n>   push: start warning upcoming default change for push.default\n\nI commented separately on patches 1 and 2, but modulo those minor\ncomments, the series looks OK to me. The \"Git 2.0\" mention in patch 4/4\nmight need to be tweaked. :)\n\n-Peff\n"},{"id":"189784","messageId":"xmqq62cum6tf.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"20120420201357.GA13103@sigill.intra.peff.net","subject":"Re: [PATCH 1/4] Documentation: explain push.default option a bit more","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-20T21:28:28Z","receivedAt":"2012-04-20T21:28:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Apr 20, 2012 at 04:59:01PM +0200, Matthieu Moy wrote:\n>\n>> The previous documentation was explaining _what_ the options were doing,\n>> but were of little help explaining _why_ a user should set his default to\n>> either of the options.\n>\n> I think your explanations are a definite improvement.\n\n<aol>Me too</aol>\n\nExcept for this part.\n\n>  * `current` - push the current branch to a branch of the same name.\n> +  This option allows publishing a branch to a remote repository using\n> +  the same naming convention locally and remotely, in a more\n> +  conservative and safer way than `matching`.\n\nI am not sure if \"in a more conservative and safer way than `matching`\"\nis a good thing to say here.  It sounds as if you are saying \"you push\nonly one, so even if it does what you did not intend to do, you inflict\ndamage to at most one branch\" and without mentioning the downside of\n\"you push only one, so you need to checkout and push out all the\nbranches one by one that you care about\".\n\nThe workflow 'current', 'upstream' and 'simple' are suitable for is\nfundamentally different from what 'matching' aims to support.\n\nThe former three are for people who want: \"I've completed this single\nbranch, the one I have had in my working tree and have been working on\nfor all this time. I'll push *that* single branch out. All the other\nbranches do not participate in this push\".\n\nThe 'matching' is for people who want: \"I've worked on the set of\nbranches I want to publish until they are _all_ ready.  And now they\nare.  Publish all of them with a single connection, atomically, in one\ngo.\"\n\nYour text that compares between 'current' and 'matching' does not make\nit clear that point.  In a workflow for which 'current' is suitable,\n'matching' is not even \"a more aggressive and riskier\" alternative.  The\ntext does not make the reader aware of that, and will invite \"current is\na more cumbersome and tedious alternative if you want to push out all\nthan matching\", which is a faulty conclusion coming from the same\nconfusion.\n\nPerhaps make this part a separate paragraph so that it stands out a bit\nmore, like this,\n\n    * `current` - push the current branch to a branch of the same name.\n    +\n    The `current` and `upstream` modes are for those who want to\n    push out a single branch after finishing work, even when the other\n    branches are not yet ready to be pushed out.\n\nand update the description for `matching` to explain why it is suited\nfor what we claim that it is suited for, like so:\n\n    * `matching` - push all branches having the same name in both ends.\n      This is for those who prepare all the branches into a publishable\n      shape and push them out atomically, and suitable when pushing to a\n      non-shared repository. It is not appropriate to use when pushing into\n      a repository shared by multiple users, since locally stalled branches\n      will attempt a non-fast forward push if other users updated the branch\n      remotely.\n    +\n    This is the default.\n"},{"id":"189785","messageId":"xmqqy5pqkrl4.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"1334933944-13446-3-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 2/4] push: introduce new push.default mode \"simple\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-20T21:42:47Z","receivedAt":"2012-04-20T21:42:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n\n> Except for the broken-ness, this adds the last line in the warning message:\n\nHmm?  What brokenness?\n\n> +\t\t      \"To chose either option permanently, read about push.default in git-config(1)\\n\"),\n\nNice ;-)\n\n> diff --git a/cache.h b/cache.h\n> index d8f6f1e..5e419a1 100644\n> --- a/cache.h\n> +++ b/cache.h\n> @@ -580,6 +580,7 @@ enum rebase_setup_type {\n>  enum push_default_type {\n>  \tPUSH_DEFAULT_NOTHING = 0,\n>  \tPUSH_DEFAULT_MATCHING,\n> +\tPUSH_DEFAULT_SIMPLE,\n>  \tPUSH_DEFAULT_UPSTREAM,\n>  \tPUSH_DEFAULT_CURRENT,\n>  \tPUSH_DEFAULT_UNSPECIFIED\n\nI think SIMPLE should come between CURRENT and UPSTREAM in the order of\nlogical progression, i.e. CURRENT < SIMPLE < UPSTREAM, because CURRENT\nis appropriate in the simplest of workflow (you clone and get master and\ndevel branches, work on master and push it out to master, work on devel\nand push it out to devel, without any need for @{upstream}), SIMPLE is a\nbit more advanced (you can take advantage of @{upstream}), and CURRENT\nwould be the most advanced, in the \"one branch at a time\" camp.\n\n> diff --git a/config.c b/config.c\n> index 68d3294..024bc74 100644\n> --- a/config.c\n> +++ b/config.c\n> @@ -837,7 +839,7 @@ static int git_default_push_config(const char *var, const char *value)\n>  \t\t\tpush_default = PUSH_DEFAULT_CURRENT;\n>  \t\telse {\n>  \t\t\terror(\"Malformed value for %s: %s\", var, value);\n> -\t\t\treturn error(\"Must be one of nothing, matching, \"\n> +\t\t\treturn error(\"Must be one of simple, nothing, matching, \"\n>  \t\t\t\t     \"tracking or current.\");\n\nAnd this should match.  I think\n\n\tnothing, matching, current, simple or upstream.\n\nwould be more natural.\n"},{"id":"189793","messageId":"4F922ECC.4040103@alum.mit.edu","threadId":"30086","inReplyTo":"xmqq62cum6tf.fsf@junio.mtv.corp.google.com","subject":"Re: [PATCH 1/4] Documentation: explain push.default option a bit more","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-04-21T03:51:40Z","receivedAt":"2012-04-21T03:51:40Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 04/20/2012 11:28 PM, Junio C Hamano wrote:\n> [...]\n> Perhaps make this part a separate paragraph so that it stands out a bit\n> more, like this,\n>\n>      * `current` - push the current branch to a branch of the same name.\n>      +\n>      The `current` and `upstream` modes are for those who want to\n>      push out a single branch after finishing work, even when the other\n>      branches are not yet ready to be pushed out.\n>\n> and update the description for `matching` to explain why it is suited\n> for what we claim that it is suited for, like so:\n>\n>      * `matching` - push all branches having the same name in both ends.\n>        This is for those who prepare all the branches into a publishable\n>        shape and push them out atomically, and suitable when pushing to a\n>        non-shared repository. It is not appropriate to use when pushing into\n>        a repository shared by multiple users, since locally stalled branches\n>        will attempt a non-fast forward push if other users updated the branch\n>        remotely.\n>      +\n>      This is the default.\n\n\"Atomic\" implies that either the whole push succeeds or the whole push \nfails, and that readers will never see part of the push.  Is full \natomicity really guaranteed?  Does the guarantee depend on the \nrepository being non-shared?  What if the repo has one writer but \nmultiple readers?\n\nI have trouble answering questions like these because I haven't figured \nout the big picture of git's locking model.  In the code, all I have \nseen so far is fine-grained locks that only block writers (though the \nfast-index GSoC proposal includes a plan to introduce a lock on the \nindex that blocks readers).  Is git's locking model documented somewhere?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"189794","messageId":"xmqqpqb1zpzz.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"4F922ECC.4040103@alum.mit.edu","subject":"Re: [PATCH 1/4] Documentation: explain push.default option a bit more","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-21T04:08:00Z","receivedAt":"2012-04-21T04:08:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> \"Atomic\" implies that either the whole push succeeds or the whole push\n> fails, and that readers will never see part of the push.\n\nOh, I didn't mean \"atomic\" in that strict sense.  After all this was a\ndescription at the workflow level--what the human user perceives.\n\nWhen pushing into the repository you control and nobody else messes\nwith, you may want update both 'master' and 'devel' with the same \"git\npush\", and that is quite different from current/upstream/simple\nmodel. That is all I meant.\n\nAt the mechanical level, we:\n\n - read all the refs we are going to update and remember their values;\n - send and store all the necessary objects; and\n - for each ref:\n    - lock it;\n    - read it;\n    - is it different from what we read originally?\n      - if so, do not update it and remember the fact that we saw a failure;\n      - otherwise update it;\n    - unlock it;\n\nso it won't be the kind of \"atomic\" in the \"if 'master' will fail to\nupdate due to non-fast-forward, not just 'master' but also 'devel' is\nnot updated\" sense.\n\n\nAlso, if you happen to observe 'devel' and 'master' when a push is in\nprogress, you may get lucky and see the new value of 'devel' and old\nvalue of 'master'. In that sense, too, it is not \"atomic\", either.\n\nIn the workflow where 'matching' is appropriate, the former won't be an\nissue. The latter might be, but it is not like you push objects for\ndevel, update devel, then push objects for master and the update master,\nso the window of race is very small.\n"},{"id":"189797","messageId":"4F923F3A.7050701@alum.mit.edu","threadId":"30086","inReplyTo":"xmqqpqb1zpzz.fsf@junio.mtv.corp.google.com","subject":"Re: [PATCH 1/4] Documentation: explain push.default option a bit more","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-04-21T05:01:46Z","receivedAt":"2012-04-21T05:01:46Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 04/21/2012 06:08 AM, Junio C Hamano wrote:\n> Michael Haggerty<mhagger@alum.mit.edu>  writes:\n>> \"Atomic\" implies that either the whole push succeeds or the whole push\n>> fails, and that readers will never see part of the push.\n>\n> Oh, I didn't mean \"atomic\" in that strict sense.  After all this was a\n> description at the workflow level--what the human user perceives.\n\nThat's what I suspected.\n\nGiven that the word \"atomic\", for technical people, has a strict meaning \nthat is not met here, and for non-technical people probably only means \n\"nuclear\", I suggest that the word be avoided in this explanation.  Perhaps\n\n>      * `matching` - push all branches having the same name in both ends.\n>        This is for those who prepare all the branches into a publishable\n>        shape and push them out atomically, and suitable when pushing to a\n>        non-shared repository. [...]\n\ncould be changed to\n\n>      * `matching` - push all branches having the same name in both ends.\n>        This allows those who prepare all the branches into a publishable\n>        shape to push them out to a non-shared repository with a single\n >        command. [...]\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"189800","messageId":"xmqqbomlzlma.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"4F923F3A.7050701@alum.mit.edu","subject":"Re: [PATCH 1/4] Documentation: explain push.default option a bit more","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-21T05:42:37Z","receivedAt":"2012-04-21T05:42:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> only means \"nuclear\", I suggest that the word be avoided in this\n> explanation.  Perhaps\n>\n>>      * `matching` - push all branches having the same name in both ends.\n>>        This is for those who prepare all the branches into a publishable\n>>        shape and push them out atomically, and suitable when pushing to a\n>>        non-shared repository. [...]\n>\n> could be changed to\n>\n>>      * `matching` - push all branches having the same name in both ends.\n>>        This allows those who prepare all the branches into a publishable\n>>        shape to push them out to a non-shared repository with a single\n>>        command. [...]\n\nSounds good.\n"},{"id":"189832","messageId":"vpqipgs81ru.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"20120420203552.GC13103@sigill.intra.peff.net","subject":"Re: [PATCH 0/4 v2] push.default upcomming change","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-22T11:05:41Z","receivedAt":"2012-04-22T11:05:41Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> The \"Git 2.0\" mention in patch 4/4 might need to be tweaked. :)\n\nThe \"Git 2.0\" comes from Junio. I don't mind changing that to \"Git 1.9.0\nor Git 2.0, whichever is released earlier\".\n\nActually, I'm starting to think that the \"warning\" part should be\ndelayed a bit: we probably want to wait for the \"simple\" implementation\nto be available widely before we start advising people to set it\nexplicitely (otherwise, people using different Git versions on different\nmachines, but sharing the same configuration will get complaints from\nGit about invalid value).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189836","messageId":"4F9430DA.4030304@in.waw.pl","threadId":"30086","inReplyTo":"20120420203324.GB13103@sigill.intra.peff.net","subject":"Re: [PATCH 2/4] push: introduce new push.default mode \"simple\"","fromName":"Zbigniew Jędrzejewski-Szmek","fromEmail":"zbyszek@in.waw.pl","sentAt":"2012-04-22T16:24:58Z","receivedAt":"2012-04-22T16:24:58Z","isPatch":true,"sender":{"key":"zbyszek@in.waw.pl","avatar":"https://avatars.githubusercontent.com/u/349618?v=4"},"body":"Some minor spelling fixes:\n\n> When calling \"git push\" without argument, we want to allow Git to do\n> something simple to explain and safe. push.default=matching is unsafe\n> when use to push to shared repositories, and hard to explain to beginners\n       used\n> in some context. It is debatable whether 'upstream' or 'current' is the\n       contexts\n> safest or the easiest to explain, so introduce a new mode called 'simple'\n> that is the intersection of them: push the upstream branch, but only if\n                                    push to the\n> it has the same name remotely. If not, give an error that suggest the\n> right command to push explicitely to 'upstream' or 'current'.\n\n\nOn 04/20/2012 10:33 PM, Jeff King wrote:\n> On Fri, Apr 20, 2012 at 04:59:02PM +0200, Matthieu Moy wrote:\n> \n>> it has the same name remotely. If not, give an error that suggest the\n>> right command to push explicitely to 'upstream' or 'current'.\n> \n> s/suggest/&s/\n> \n>> beneficial on the next pull. Lacking better argument, we chose to deny\n>> the push, because it will be easier to change in the future is someone\n>> shows us wrong.\n> \n> s/is/if/\n> \n>> Original-patch-by: Jeff King <peff@peff.net>\n>> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n>> ---\n>> Except for the broken-ness, this adds the last line in the warning message:\n>>\n>> \"To chose either option permanently, read about push.default in git-config(1)\"\n       choose\n\n> I don't think that makes sense if I have set \"push.default\" to \"simple\"\n> myself. IOW, shouldn't that get added later, when it eventually becomes\n> the default (and then, only when it was chosen because it is the\n> default, not because somebody explicitly said they wanted it)?\n\n-\nZbyszek\n"},{"id":"189847","messageId":"xmqqzka3kvpz.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"vpqipgs81ru.fsf@bauges.imag.fr","subject":"Re: [PATCH 0/4 v2] push.default upcomming change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T02:50:16Z","receivedAt":"2012-04-23T02:50:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Actually, I'm starting to think that the \"warning\" part should be\n> delayed a bit: we probably want to wait for the \"simple\" implementation\n> to be available widely before we start advising people to set it\n> explicitely (otherwise, people using different Git versions on different\n> machines, but sharing the same configuration will get complaints from\n> Git about invalid value).\n\nYes, that is a good thinking.\n"},{"id":"189851","messageId":"1335170284-30768-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1334933944-13446-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 0/7 v3] push.default upcomming change","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-23T08:37:57Z","receivedAt":"2012-04-23T08:37:57Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"I think I've applied all feedback I've received.\n\nAdditionnally, I've split the \"start warning\" patch in a documentation\npatch, that is meant to be applied now, and the warning patch itself,\nwhich is meant to be applied after the first released version\nintroducing 'simple': we don't want to advertize 'simple' too loudly\nuntil the option starts being deployed.\n\nClemens Buchacher (1):\n  t5570: use explicit push refspec\n\nMatthieu Moy (6):\n  Documentation: explain push.default option a bit more\n  Undocument deprecated alias 'push.default=tracking'\n  t5528-push-default.sh: add helper functions\n  push: introduce new push.default mode \"simple\"\n  push: document the future default change for push.default (matching\n    -> simple)\n  push: start warning upcoming default change for push.default\n\n Documentation/config.txt |   28 ++++++++++++---\n builtin/push.c           |   71 +++++++++++++++++++++++++++++++++---\n cache.h                  |    1 +\n config.c                 |    6 ++--\n t/t5528-push-default.sh  |   89 ++++++++++++++++++++++++++++++++++++++++++----\n t/t5570-git-daemon.sh    |   30 ++++++++--------\n 6 files changed, 191 insertions(+), 34 deletions(-)\n\n-- \n1.7.10.234.ge65dd.dirty\n"},{"id":"189854","messageId":"1335170284-30768-2-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335170284-30768-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 1/7] Documentation: explain push.default option a bit more","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-23T08:37:58Z","receivedAt":"2012-04-23T08:37:58Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"The previous documentation was explaining _what_ the options were doing,\nbut were of little help explaining _why_ a user should set his default to\neither of the options.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n Documentation/config.txt |   22 ++++++++++++++++++----\n 1 file changed, 18 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex fb386ab..e38fab1 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1680,12 +1680,26 @@ push.default::\n \tline. Possible values are:\n +\n * `nothing` - do not push anything.\n-* `matching` - push all matching branches.\n-  All branches having the same name in both ends are considered to be\n-  matching. This is the default.\n-* `upstream` - push the current branch to its upstream branch.\n+* `matching` - push all branches having the same name in both ends.\n+  This allows those who prepare all the branches into a publishable\n+  shape to push them out to a non-shared repository with a single\n+  command. This is well suited when pushing to a non-shared\n+  repository, but may give surprising results when used on a\n+  repository shared by multiple users, since locally stalled\n+  branches will attempt a non-fast forward push if other users\n+  updated the branch remotely. This is the default.\n+* `upstream` - push the current branch to its upstream branch. See\n+  \"branch.<name>.merge\" for how to configure the upstream branch. This\n+  makes `git push` and `git pull` symmetrical in the sense that `push`\n+  will update the same remote ref as the one which is merged by\n+  `git pull`.\n * `tracking` - deprecated synonym for `upstream`.\n * `current` - push the current branch to a branch of the same name.\n+  +\n+  The `current` and `upstream` modes are for those who want to\n+  push out a single branch after finishing work, even when the other\n+  branches are not yet ready to be pushed out. They are safe when\n+  pushing to a shared repository.\n \n rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\n-- \n1.7.10.234.ge65dd.dirty\n"},{"id":"189850","messageId":"1335170284-30768-3-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335170284-30768-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-23T08:37:59Z","receivedAt":"2012-04-23T08:37:59Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,\npush.default: Rename 'tracking' to 'upstream'), so it's OK to remove it\nfrom documentation (even though it's still supported) to make the\nexplanations more readable.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\nFeel free to squash into previous one if needed.\n\n Documentation/config.txt |    1 -\n 1 file changed, 1 deletion(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex e38fab1..ddf6043 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1693,7 +1693,6 @@ push.default::\n   makes `git push` and `git pull` symmetrical in the sense that `push`\n   will update the same remote ref as the one which is merged by\n   `git pull`.\n-* `tracking` - deprecated synonym for `upstream`.\n * `current` - push the current branch to a branch of the same name.\n   +\n   The `current` and `upstream` modes are for those who want to\n-- \n1.7.10.234.ge65dd.dirty\n"},{"id":"189852","messageId":"1335170284-30768-4-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335170284-30768-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 3/7] t5528-push-default.sh: add helper functions","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-23T08:38:00Z","receivedAt":"2012-04-23T08:38:00Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n t/t5528-push-default.sh |   45 ++++++++++++++++++++++++++++++++++++++-------\n 1 file changed, 38 insertions(+), 7 deletions(-)\n\ndiff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\nindex c334c51..da7d3d8 100755\n--- a/t/t5528-push-default.sh\n+++ b/t/t5528-push-default.sh\n@@ -13,16 +13,47 @@ test_expect_success 'setup bare remotes' '\n \tgit push parent2 HEAD\n '\n \n+# $1 = local revision\n+# $2 = remote revision (tested to be equal to the local one)\n+check_pushed_commit () {\n+\tgit log -1 --format='%h %s' >expect &&\n+\tgit --git-dir=repo1 log -1 --format='%h %s' \"$2\" >actual &&\n+\ttest_cmp expect actual\n+}\n+\n+# $1 = push.default value\n+# $2 = expected target branch for the push\n+test_push_success () {\n+\tgit -c push.default=\"$1\" push &&\n+\tcheck_pushed_commit HEAD \"$2\"\n+}\n+\n+# $1 = push.default value\n+# other arguments = target branches that should not be touched\n+test_push_failure () {\n+\tpush_default=$1 &&\n+\tshift &&\n+\tif test $# -gt 0\n+\tthen\n+\t\t# branch may not exist\n+\t\ttest_might_fail git --git-dir=repo1 \\\n+\t\t\tlog --no-walk --format='%h %s' \"$@\" >expect\n+\tfi &&\n+\ttest_must_fail git -c push.default=\"$1\" &&\n+\tif test $# -gt 0\n+\tthen\n+\t\ttest_might_fail git --git-dir=repo1 \\\n+\t\t\tlog -1 --format='%h %s' \"$@\" >actual\n+\tfi &&\n+\ttest_cmp expect actual\n+}\n+\n test_expect_success '\"upstream\" pushes to configured upstream' '\n \tgit checkout master &&\n \ttest_config branch.master.remote parent1 &&\n \ttest_config branch.master.merge refs/heads/foo &&\n-\ttest_config push.default upstream &&\n \ttest_commit two &&\n-\tgit push &&\n-\techo two >expect &&\n-\tgit --git-dir=repo1 log -1 --format=%s foo >actual &&\n-\ttest_cmp expect actual\n+\ttest_push_success upstream foo\n '\n \n test_expect_success '\"upstream\" does not push on unconfigured remote' '\n@@ -30,7 +61,7 @@ test_expect_success '\"upstream\" does not push on unconfigured remote' '\n \ttest_unconfig branch.master.remote &&\n \ttest_config push.default upstream &&\n \ttest_commit three &&\n-\ttest_must_fail git push\n+\ttest_push_failure upstream master\n '\n \n test_expect_success '\"upstream\" does not push on unconfigured branch' '\n@@ -39,7 +70,7 @@ test_expect_success '\"upstream\" does not push on unconfigured branch' '\n \ttest_unconfig branch.master.merge &&\n \ttest_config push.default upstream\n \ttest_commit four &&\n-\ttest_must_fail git push\n+\ttest_push_failure upstream master\n '\n \n test_expect_success '\"upstream\" does not push when remotes do not match' '\n-- \n1.7.10.234.ge65dd.dirty\n"},{"id":"189857","messageId":"1335170284-30768-5-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335170284-30768-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 4/7] push: introduce new push.default mode \"simple\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-23T08:38:01Z","receivedAt":"2012-04-23T08:38:01Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"When calling \"git push\" without argument, we want to allow Git to do\nsomething simple to explain and safe. push.default=matching is unsafe\nwhen used to push to shared repositories, and hard to explain to\nbeginners in some contexts. It is debatable whether 'upstream' or\n'current' is the safest or the easiest to explain, so introduce a new\nmode called 'simple' that is the intersection of them: push to the\nupstream branch, but only if it has the same name remotely. If not, give\nan error that suggests the right command to push explicitely to\n'upstream' or 'current'.\n\nA question is whether to allow pushing when no upstream is configured. An\nargument in favor of allowing the push is that it makes the new mode work\nin more cases. On the other hand, refusing to push when no upstream is\nconfigured encourages the user to set the upstream, which will be\nbeneficial on the next pull. Lacking better argument, we chose to deny\nthe push, because it will be easier to change in the future if someone\nshows us wrong.\n\nOriginal-patch-by: Jeff King <peff@peff.net>\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n Documentation/config.txt |    5 ++++-\n builtin/push.c           |   44 ++++++++++++++++++++++++++++++++++++++++++--\n cache.h                  |    1 +\n config.c                 |    6 ++++--\n t/t5528-push-default.sh  |   44 ++++++++++++++++++++++++++++++++++++++++++++\n 5 files changed, 95 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex ddf6043..88d739a 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1688,6 +1688,9 @@ push.default::\n   repository shared by multiple users, since locally stalled\n   branches will attempt a non-fast forward push if other users\n   updated the branch remotely. This is the default.\n+* `simple` - like `upstream`, but refuses to push if the upstream\n+  branch's name is different from the local one. This is the safest\n+  option and is well-suited for beginners.\n * `upstream` - push the current branch to its upstream branch. See\n   \"branch.<name>.merge\" for how to configure the upstream branch. This\n   makes `git push` and `git pull` symmetrical in the sense that `push`\n@@ -1695,7 +1698,7 @@ push.default::\n   `git pull`.\n * `current` - push the current branch to a branch of the same name.\n   +\n-  The `current` and `upstream` modes are for those who want to\n+  The `simple`, `current` and `upstream` modes are for those who want to\n   push out a single branch after finishing work, even when the other\n   branches are not yet ready to be pushed out. They are safe when\n   pushing to a shared repository.\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 6936713..dae8306 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -76,7 +76,40 @@ static int push_url_of_remote(struct remote *remote, const char ***url_p)\n \treturn remote->url_nr;\n }\n \n-static void setup_push_upstream(struct remote *remote)\n+NORETURN die_push_simple(struct branch *branch, struct remote *remote) {\n+\t/*\n+\t * There's no point in using shorten_unambiguous_ref here,\n+\t * as the ambiguity would be on the remote side, not what\n+\t * we have locally. Plus, this is supposed to be the simple\n+\t * mode. If the user is doing something crazy like setting\n+\t * upstream to a non-branch, we should probably be showing\n+\t * them the big ugly fully qualified ref.\n+\t */\n+\tconst char *short_up = skip_prefix(branch->merge[0]->src, \"refs/heads/\");\n+\t/*\n+\t * Don't show advice for people who explicitely set\n+\t * push.default.\n+\t */\n+\tconst char *advice_maybe = \"\";\n+\tif (push_default == PUSH_DEFAULT_UNSPECIFIED)\n+\t\tadvice_maybe = _(\"\\n\"\n+\t\t\t\t \"To choose either option permanently, \"\n+\t\t\t\t \"see push.default in 'git help config'.\");\n+\tdie(_(\"The upstream branch of your current branch does not match\\n\"\n+\t      \"the name of your current branch.  To push to the upstream branch\\n\"\n+\t      \"on the remote, use\\n\"\n+\t      \"\\n\"\n+\t      \"    git push %s HEAD:%s\\n\"\n+\t      \"\\n\"\n+\t      \"To push to the branch of the same name on the remote, use\\n\"\n+\t      \"\\n\"\n+\t      \"    git push %s %s\\n\"\n+\t      \"%s\"),\n+\t    remote->name, short_up ? short_up : branch->merge[0]->src,\n+\t    remote->name, branch->name, advice_maybe);\n+}\n+\n+static void setup_push_upstream(struct remote *remote, int simple)\n {\n \tstruct strbuf refspec = STRBUF_INIT;\n \tstruct branch *branch = branch_get(NULL);\n@@ -103,6 +136,9 @@ static void setup_push_upstream(struct remote *remote)\n \t\t      \"your current branch '%s', without telling me what to push\\n\"\n \t\t      \"to update which remote branch.\"),\n \t\t    remote->name, branch->name);\n+\tif (simple && strcmp(branch->refname, branch->merge[0]->src)) {\n+\t\tdie_push_simple(branch, remote);\n+\t}\n \n \tstrbuf_addf(&refspec, \"%s:%s\", branch->name, branch->merge[0]->src);\n \tadd_refspec(refspec.buf);\n@@ -119,8 +155,12 @@ static void setup_default_push_refspecs(struct remote *remote)\n \t\tadd_refspec(\":\");\n \t\tbreak;\n \n+\tcase PUSH_DEFAULT_SIMPLE:\n+\t\tsetup_push_upstream(remote, 1);\n+\t\tbreak;\n+\n \tcase PUSH_DEFAULT_UPSTREAM:\n-\t\tsetup_push_upstream(remote);\n+\t\tsetup_push_upstream(remote, 0);\n \t\tbreak;\n \n \tcase PUSH_DEFAULT_CURRENT:\ndiff --git a/cache.h b/cache.h\nindex 5bf59ff..b60d490 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -624,6 +624,7 @@ enum rebase_setup_type {\n enum push_default_type {\n \tPUSH_DEFAULT_NOTHING = 0,\n \tPUSH_DEFAULT_MATCHING,\n+\tPUSH_DEFAULT_SIMPLE,\n \tPUSH_DEFAULT_UPSTREAM,\n \tPUSH_DEFAULT_CURRENT,\n \tPUSH_DEFAULT_UNSPECIFIED\ndiff --git a/config.c b/config.c\nindex 68d3294..bfe0c79 100644\n--- a/config.c\n+++ b/config.c\n@@ -829,6 +829,8 @@ static int git_default_push_config(const char *var, const char *value)\n \t\t\tpush_default = PUSH_DEFAULT_NOTHING;\n \t\telse if (!strcmp(value, \"matching\"))\n \t\t\tpush_default = PUSH_DEFAULT_MATCHING;\n+\t\telse if (!strcmp(value, \"simple\"))\n+\t\t\tpush_default = PUSH_DEFAULT_SIMPLE;\n \t\telse if (!strcmp(value, \"upstream\"))\n \t\t\tpush_default = PUSH_DEFAULT_UPSTREAM;\n \t\telse if (!strcmp(value, \"tracking\")) /* deprecated */\n@@ -837,8 +839,8 @@ static int git_default_push_config(const char *var, const char *value)\n \t\t\tpush_default = PUSH_DEFAULT_CURRENT;\n \t\telse {\n \t\t\terror(\"Malformed value for %s: %s\", var, value);\n-\t\t\treturn error(\"Must be one of nothing, matching, \"\n-\t\t\t\t     \"tracking or current.\");\n+\t\t\treturn error(\"Must be one of nothing, matching, simple, \"\n+\t\t\t\t     \"upstream or current.\");\n \t\t}\n \t\treturn 0;\n \t}\ndiff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\nindex da7d3d8..43dec43 100755\n--- a/t/t5528-push-default.sh\n+++ b/t/t5528-push-default.sh\n@@ -82,4 +82,48 @@ test_expect_success '\"upstream\" does not push when remotes do not match' '\n \ttest_must_fail git push parent2\n '\n \n+test_expect_success 'push from/to new branch with upstream, matching and simple' '\n+\tgit checkout -b new-branch &&\n+\ttest_push_failure simple new-branch &&\n+\ttest_push_failure matching new-branch &&\n+\ttest_push_failure upstream new-branch\n+'\n+\n+test_expect_success 'push from/to new branch with current creates remote branch' '\n+\ttest_config branch.new-branch.remote repo1 &&\n+\tgit checkout new-branch &&\n+\ttest_push_success current new-branch\n+'\n+\n+test_expect_success 'push to existing branch, with no upstream configured' '\n+\ttest_config branch.master.remote repo1 &&\n+\tgit checkout master &&\n+\ttest_push_failure simple master &&\n+\ttest_push_failure upstream master\n+'\n+\n+test_expect_success 'push to existing branch, upstream configured with same name' '\n+\ttest_config branch.master.remote repo1 &&\n+\ttest_config branch.master.merge refs/heads/master &&\n+\tgit checkout master &&\n+\ttest_commit six &&\n+\ttest_push_success upstream master &&\n+\ttest_commit seven &&\n+\ttest_push_success simple master\n+'\n+\n+test_expect_success 'push to existing branch, upstream configured with different name' '\n+\ttest_config branch.master.remote repo1 &&\n+\ttest_config branch.master.merge refs/heads/other-name &&\n+\tgit checkout master &&\n+\ttest_commit eight &&\n+\ttest_push_success upstream other-name &&\n+\ttest_commit nine &&\n+\ttest_push_failure simple new-branch &&\n+\tgit --git-dir=repo1 log -1 --format=\"%h %s\" \"other-name\" >expect-other-name &&\n+\ttest_push_success current master &&\n+\tgit --git-dir=repo1 log -1 --format=\"%h %s\" \"other-name\" >actual-other-name &&\n+\ttest_cmp expect-other-name actual-other-name\n+'\n+\n test_done\n-- \n1.7.10.234.ge65dd.dirty\n"},{"id":"189858","messageId":"1335170284-30768-6-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335170284-30768-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 5/7] t5570: use explicit push refspec","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-23T08:38:02Z","receivedAt":"2012-04-23T08:38:02Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"From: Clemens Buchacher <drizzd@aon.at>\n\nThe default mode for push without arguments will change. Some warnings\nare about to be enabled for such use, which causes some t5570 tests to\nfail because they do not expect this output.\n\nFix this by passing an explicit refspec to git push. To that end, change\nthe calling conventions of test_remote_error in order to accomodate\nextra command arguments.\n\nSigned-off-by: Clemens Buchacher <drizzd@aon.at>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n t/t5570-git-daemon.sh |   30 ++++++++++++++----------------\n 1 file changed, 14 insertions(+), 16 deletions(-)\n\ndiff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh\nindex 7cbc999..a3a4e47 100755\n--- a/t/t5570-git-daemon.sh\n+++ b/t/t5570-git-daemon.sh\n@@ -103,14 +103,12 @@ test_remote_error()\n \t\tesac\n \tdone\n \n-\tif test $# -ne 3\n-\tthen\n-\t\terror \"invalid number of arguments\"\n-\tfi\n-\n+\tmsg=$1\n+\tshift\n \tcmd=$1\n-\trepo=$2\n-\tmsg=$3\n+\tshift\n+\trepo=$1\n+\tshift || error \"invalid number of arguments\"\n \n \tif test -x \"$GIT_DAEMON_DOCUMENT_ROOT_PATH/$repo\"\n \tthen\n@@ -122,7 +120,7 @@ test_remote_error()\n \t\tfi\n \tfi\n \n-\ttest_must_fail git \"$cmd\" \"$GIT_DAEMON_URL/$repo\" 2>output &&\n+\ttest_must_fail git \"$cmd\" \"$GIT_DAEMON_URL/$repo\" \"$@\" 2>output &&\n \techo \"fatal: remote error: $msg: /$repo\" >expect &&\n \ttest_cmp expect output\n \tret=$?\n@@ -131,18 +129,18 @@ test_remote_error()\n }\n \n msg=\"access denied or repository not exported\"\n-test_expect_success 'clone non-existent' \"test_remote_error    clone nowhere.git '$msg'\"\n-test_expect_success 'push disabled'      \"test_remote_error    push  repo.git    '$msg'\"\n-test_expect_success 'read access denied' \"test_remote_error -x fetch repo.git    '$msg'\"\n-test_expect_success 'not exported'       \"test_remote_error -n fetch repo.git    '$msg'\"\n+test_expect_success 'clone non-existent' \"test_remote_error    '$msg' clone nowhere.git    \"\n+test_expect_success 'push disabled'      \"test_remote_error    '$msg' push  repo.git master\"\n+test_expect_success 'read access denied' \"test_remote_error -x '$msg' fetch repo.git       \"\n+test_expect_success 'not exported'       \"test_remote_error -n '$msg' fetch repo.git       \"\n \n stop_git_daemon\n start_git_daemon --informative-errors\n \n-test_expect_success 'clone non-existent' \"test_remote_error    clone nowhere.git 'no such repository'\"\n-test_expect_success 'push disabled'      \"test_remote_error    push  repo.git    'service not enabled'\"\n-test_expect_success 'read access denied' \"test_remote_error -x fetch repo.git    'no such repository'\"\n-test_expect_success 'not exported'       \"test_remote_error -n fetch repo.git    'repository not exported'\"\n+test_expect_success 'clone non-existent' \"test_remote_error    'no such repository'      clone nowhere.git    \"\n+test_expect_success 'push disabled'      \"test_remote_error    'service not enabled'     push  repo.git master\"\n+test_expect_success 'read access denied' \"test_remote_error -x 'no such repository'      fetch repo.git       \"\n+test_expect_success 'not exported'       \"test_remote_error -n 'repository not exported' fetch repo.git       \"\n \n stop_git_daemon\n test_done\n-- \n1.7.10.234.ge65dd.dirty\n"},{"id":"189853","messageId":"1335170284-30768-7-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335170284-30768-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 6/7] push: document the future default change for push.default (matching -> simple)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-23T08:38:03Z","receivedAt":"2012-04-23T08:38:03Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"It is too early to start warning loudly about the future default change\nin favor of 'simple', since many users use different versions of Git, and\nwould be harmed if we advised them to explicitely set\n'push.default=simple' when using old versions of Git.\n\nStill, we want to document the upcomming change so that:\n\n* Users who may be affected by the change get one more chance to know it\n  in advance.\n\n* We actually commit to changing the default, and avoid repeating past\n  errors.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n Documentation/config.txt |    6 ++++--\n 1 file changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 88d739a..696544e 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1687,10 +1687,12 @@ push.default::\n   repository, but may give surprising results when used on a\n   repository shared by multiple users, since locally stalled\n   branches will attempt a non-fast forward push if other users\n-  updated the branch remotely. This is the default.\n+  updated the branch remotely. This is currently the default, but Git\n+  2.0 will change the default to `simple`.\n * `simple` - like `upstream`, but refuses to push if the upstream\n   branch's name is different from the local one. This is the safest\n-  option and is well-suited for beginners.\n+  option and is well-suited for beginners. It will become the default\n+  in Git 2.0.\n * `upstream` - push the current branch to its upstream branch. See\n   \"branch.<name>.merge\" for how to configure the upstream branch. This\n   makes `git push` and `git pull` symmetrical in the sense that `push`\n-- \n1.7.10.234.ge65dd.dirty\n"},{"id":"189855","messageId":"1335170284-30768-8-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335170284-30768-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 7/7] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-23T08:38:04Z","receivedAt":"2012-04-23T08:38:04Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"In preparation for flipping the default to the \"simple\" mode from\nthe \"matching\" mode that is the historical default, start warning\nusers when they rely on unconfigured \"git push\" to default to the\n\"matching\" mode.\n\nAlso, advertise for 'simple' where 'current' and 'upstream' are advised.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n builtin/push.c |   27 +++++++++++++++++++++++++--\n 1 file changed, 25 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex dae8306..7a845a8 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -144,12 +144,35 @@ static void setup_push_upstream(struct remote *remote, int simple)\n \tadd_refspec(refspec.buf);\n }\n \n+static char warn_unspecified_push_default_msg[] =\n+N_(\"push.default is unset; its implicit value is changing in\\n\"\n+   \"Git 2.0 from 'matching' to 'simple'. To squelch this message\\n\"\n+   \"and maintain the current behavior after the default changes, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default matching\\n\"\n+   \"\\n\"\n+   \"To squelch this message and adopt the new behavior now, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default simple\\n\"\n+   \"\\n\"\n+   \"See 'git help config' and search for 'push.default' for further information.\");\n+\n+static void warn_unspecified_push_default_configuration(void)\n+{\n+\tstatic int warn_once;\n+\n+\tif (warn_once++)\n+\t\treturn;\n+\twarning(\"%s\\n\", _(warn_unspecified_push_default_msg));\n+}\n+\n static void setup_default_push_refspecs(struct remote *remote)\n {\n \tswitch (push_default) {\n \tdefault:\n \tcase PUSH_DEFAULT_UNSPECIFIED:\n \t\tdefault_matching_used = 1;\n+\t\twarn_unspecified_push_default_configuration();\n \t\t/* fallthru */\n \tcase PUSH_DEFAULT_MATCHING:\n \t\tadd_refspec(\":\");\n@@ -183,8 +206,8 @@ static const char message_advice_pull_before_push[] =\n static const char message_advice_use_upstream[] =\n \tN_(\"Updates were rejected because a pushed branch tip is behind its remote\\n\"\n \t   \"counterpart. If you did not intend to push that branch, you may want to\\n\"\n-\t   \"specify branches to push or set the 'push.default' configuration\\n\"\n-\t   \"variable to 'current' or 'upstream' to push only the current branch.\");\n+\t   \"specify branches to push or set the 'push.default' configuration variable\\n\"\n+\t   \"to 'simple', 'current' or 'upstream' to push only the current branch.\");\n \n static const char message_advice_checkout_pull_push[] =\n \tN_(\"Updates were rejected because a pushed branch tip is behind its remote\\n\"\n-- \n1.7.10.234.ge65dd.dirty\n"},{"id":"189856","messageId":"vpq397u4zcd.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"xmqqy5pqkrl4.fsf@junio.mtv.corp.google.com","subject":"Re: [PATCH 2/4] push: introduce new push.default mode \"simple\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-23T08:38:42Z","receivedAt":"2012-04-23T08:38:42Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n>\n>> Except for the broken-ness, this adds the last line in the warning message:\n>\n> Hmm?  What brokenness?\n\nThe brokenness of my previous iteration.\n\n>> +\t\t      \"To chose either option permanently, read about push.default in git-config(1)\\n\"),\n>\n> Nice ;-)\n\nBut as Jeff pointed out, this should be displayed only if the option\nhasn't been set explicitely.\n\n> I think SIMPLE should come between CURRENT and UPSTREAM in the order of\n> logical progression, i.e. CURRENT < SIMPLE < UPSTREAM,\n\nI disagree. There's actually a partial order with SIMPLE < CURRENT,\nSIMPLE < UPSTREAM, and CURRENT not comparable with UPSTREAM. Any\nsuccessfull push with SIMPLE would have done exactly the same thing for\neither CURRENT and UPSTREAM.\n\n> SIMPLE is a bit more advanced (you can take advantage of\n> @{upstream})\n\nYou don't really \"take advantage of @{upstream}\". You just get\nsuspicious pushes denied.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189859","messageId":"4F952FD9.90806@alum.mit.edu","threadId":"30086","inReplyTo":"1335170284-30768-5-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 4/7] push: introduce new push.default mode \"simple\"","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-04-23T10:32:57Z","receivedAt":"2012-04-23T10:32:57Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 04/23/2012 10:38 AM, Matthieu Moy wrote:\n> [...]\n> A question is whether to allow pushing when no upstream is configured. An\n> argument in favor of allowing the push is that it makes the new mode work\n> in more cases. On the other hand, refusing to push when no upstream is\n> configured encourages the user to set the upstream, which will be\n> beneficial on the next pull. Lacking better argument, we chose to deny\n> the push, because it will be easier to change in the future if someone\n> shows us wrong.\n\nI like your conservative approach to this decision.  I agree that a push \nthat would create a new branch on the remote server should fail if no \nupstream is configured.\n\nBut what do people think about letting push succeed when no upstream is \nconfigured *provided that* there is already a branch on the remote \nserver with the same name as the current branch?  I think this policy \nwould cover the bulk of \"safe\" scenarios without adding \ndangerous/ambiguous ones.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"189860","messageId":"vpqy5pmu22q.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"4F952FD9.90806@alum.mit.edu","subject":"Re: [PATCH 4/7] push: introduce new push.default mode \"simple\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-23T11:20:29Z","receivedAt":"2012-04-23T11:20:29Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> I like your conservative approach to this decision.\n\nConservativeness is not the only argument. I originally thought we\nshould follow 'current' when no upstream is configured, but I changed my\nmind noticing that the error message suggests \"git push --set-upstream\".\n\nThe question is, if the user has no upstream configured, whether we\nshould let him continue without configuring it, or whether it's better\nto encourage him to set the upstream.\n\nI can see senarios where people would want to push to current, and merge\nfrom @{upstream} (e.g. push = publish, pull = get changes from another\ndeveloper). But I think most if not all senarios would benefit from\nhaving the upstream configured (even if you never pull, the ability to\nrun \"git log ^@{upstream}\", or argumentless \"git rebase -i\" and the\nhints in \"git status\" telling you how many unpushed revisions you have\nare nice).\n\nNow, I agree that \"denying the push with an advice\" is a bit too strong\nwhen the goal is \"encourraging to set upstream\", so that's why I think\nit's debatable.\n\n> But what do people think about letting push succeed when no upstream\n> is configured *provided that* there is already a branch on the remote\n> server with the same name as the current branch?  I think this policy\n> would cover the bulk of \"safe\" scenarios without adding\n> dangerous/ambiguous ones.\n\nNo strong opinion. My arguments above argue in favor of rejecting this,\nbut I'd be fine with that.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189879","messageId":"xmqqr4velbkq.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"1335170284-30768-2-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 1/7] Documentation: explain push.default option a bit more","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T15:20:04Z","receivedAt":"2012-04-23T15:20:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n\n> The previous documentation was explaining _what_ the options were doing,\n> but were of little help explaining _why_ a user should set his default to\n> either of the options.\n\nThanks.\n\n>  * `nothing` - do not push anything.\n> +* `matching` - push all branches having the same name in both ends.\n> +  This allows those who prepare all the branches into a publishable\n> +  shape to push them out to a non-shared repository with a single\n> +  command. This is well suited when pushing to a non-shared\n> +  repository, but may give surprising results when used on a\n> +  repository shared by multiple users, since locally stalled\n> +  branches will attempt a non-fast forward push if other users\n> +  updated the branch remotely. This is the default.\n\nThe thought does not flow smoothly with the repetition of \"non-shared\"\nhere.  How about rephrasing it a bit, perhaps like this?\n\n  * `matching` - push all branches having the same name in both ends.\n\n    This is for those who prepare all the branches into a publishable\n    shape and then push them out with a single command.  It is not\n    appropriate for pushing into a\n    repository shared by multiple users, since locally stalled\n    branches will attempt a non-fast forward push if other users\n    updated the branch.\n    \n    This is the default.\n\n> +* `upstream` - push the current branch to its upstream branch. See\n> +  \"branch.<name>.merge\" for how to configure the upstream branch. This\n> +  makes `git push` and `git pull` symmetrical in the sense that `push`\n> +  will update the same remote ref as the one which is merged by\n> +  `git pull`.\n\nReordering the sentences may make it read better; first tell the reader\nwhy and what enough so that they can decide if this is good for her and\nthen tell her how to configure it.\n\n  * `upstream` - push the current branch to its upstream branch. \n\n    With this, `git push` will update the same remote ref as the one which\n    is merged by `git pull`, making `push` and `pull` symmetrical.\n    See \"branch.<name>.merge\" for how to configure the upstream branch. \n\n>  * `tracking` - deprecated synonym for `upstream`.\n>  * `current` - push the current branch to a branch of the same name.\n> +  +\n> +  The `current` and `upstream` modes are for those who want to\n> +  push out a single branch after finishing work, even when the other\n> +  branches are not yet ready to be pushed out. They are safe when\n> +  pushing to a shared repository.\n\nDo we really want to say \"safe\" here?  I think it is misleading in\nmultiple ways.\n\n - If your current branch has a name differnt from its upstream, using\n   `current` when you meant `upstream` may result in the embarrasing\n   fast forward discussed elsewhere, which is hardly \"safe\".\n\n - If you always make everything on your end ready before pushing things\n   out, `matching` may attempt to update remote branches other than the\n   one that corresponds to your current branch, but that is exactly what\n   you want to see---there is no danger here.  You can make it dangerous\n   with --force, but that is a separate issue.\n\n - An attempt to push a stale branch in all cases will error out without\n   causing damage to the remote repository.  If you do not keep your\n   branches up-to-date and still use `matching`, you have more chance of\n   seeing this when used against a shared repository. It is unclear if\n   the use of word \"safe\" in the above description means this \"you are\n   behind\" error \"a risk to be avoided\", but\n\n    - if so, `current` or `upstream` will see the same error in a shared\n      repository where the same branch is updated by multiple people, so\n      \"They are safe\" is not quite correct; and\n\n    - if not, then `matching` is not less safe than others (it is just\n      as safe and unsafe as `current`).\n\nThere is a high correlation between use of shared repository and the\nstyle of \"working on one branch at a time, pushing the result as soon as\nthat single branch is OK\", so I am perfectly fine with saying that these\nsingle-branch modes are most likely what people want to use when working\nwith a shared repository, but I do not think `safety` has much to do\nwith the choice.\n\n\t\n"},{"id":"189880","messageId":"xmqqmx62lbj6.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"1335170284-30768-3-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T15:21:01Z","receivedAt":"2012-04-23T15:21:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n\n> It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,\n> push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it\n> from documentation (even though it's still supported) to make the\n> explanations more readable.\n>\n> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n> ---\n> Feel free to squash into previous one if needed.\n\nThanks, but let's keep it separate.\n\n>  Documentation/config.txt |    1 -\n>  1 file changed, 1 deletion(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index e38fab1..ddf6043 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1693,7 +1693,6 @@ push.default::\n>    makes `git push` and `git pull` symmetrical in the sense that `push`\n>    will update the same remote ref as the one which is merged by\n>    `git pull`.\n> -* `tracking` - deprecated synonym for `upstream`.\n>  * `current` - push the current branch to a branch of the same name.\n>    +\n>    The `current` and `upstream` modes are for those who want to\n"},{"id":"189881","messageId":"xmqqipgqlass.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"1335170284-30768-4-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 3/7] t5528-push-default.sh: add helper functions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T15:36:51Z","receivedAt":"2012-04-23T15:36:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n\n> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n> ---\n>  t/t5528-push-default.sh |   45 ++++++++++++++++++++++++++++++++++++++-------\n>  1 file changed, 38 insertions(+), 7 deletions(-)\n\nThe use of helpers makes the body of the test easier to follow.\n\n> diff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\n> index c334c51..da7d3d8 100755\n> --- a/t/t5528-push-default.sh\n> +++ b/t/t5528-push-default.sh\n> @@ -13,16 +13,47 @@ test_expect_success 'setup bare remotes' '\n>  \tgit push parent2 HEAD\n>  '\n>  \n> +# $1 = local revision\n> +# $2 = remote revision (tested to be equal to the local one)\n> +check_pushed_commit () {\n> +\tgit log -1 --format='%h %s' >expect &&\n> +\tgit --git-dir=repo1 log -1 --format='%h %s' \"$2\" >actual &&\n> +\ttest_cmp expect actual\n> +}\n\nHmph.  How is $1 used in the above to make it compare between local and\nremote?  Does the first one need to have \"$1\" before \" >expect\"?\n\n> +# $1 = push.default value\n> +# $2 = expected target branch for the push\n> +test_push_success () {\n> +\tgit -c push.default=\"$1\" push &&\n> +\tcheck_pushed_commit HEAD \"$2\"\n> +}\n> +\n> +# $1 = push.default value\n> +# other arguments = target branches that should not be touched\n> +test_push_failure () {\n> +\tpush_default=$1 &&\n> +\tshift &&\n> +\tif test $# -gt 0\n> +\tthen\n> +\t\t# branch may not exist\n> +\t\ttest_might_fail git --git-dir=repo1 \\\n> +\t\t\tlog --no-walk --format='%h %s' \"$@\" >expect\n> +\tfi &&\n> +\ttest_must_fail git -c push.default=\"$1\" &&\n\nWhat subcommand does this run with one-shot override configuration?  Do\nwe need \" push\" before \" &&\"?\n\n> +\tif test $# -gt 0\n> +\tthen\n> +\t\ttest_might_fail git --git-dir=repo1 \\\n> +\t\t\tlog -1 --format='%h %s' \"$@\" >actual\n> +\tfi &&\n> +\ttest_cmp expect actual\n> +}\n\nThis allows us to look at not just the failure of the push operation,\nbut also inspects the resulting repository to make sure things that must\nstay intact do, which is very nice.  The callers can even pass \"--all\"\nto it, instead of enumerating the branches, which would be very useful\nwhen testing a single-branch modes like `current` and `upstream`.\n\n>  test_expect_success '\"upstream\" pushes to configured upstream' '\n>  \tgit checkout master &&\n>  \ttest_config branch.master.remote parent1 &&\n>  \ttest_config branch.master.merge refs/heads/foo &&\n> -\ttest_config push.default upstream &&\n>  \ttest_commit two &&\n> -\tgit push &&\n> -\techo two >expect &&\n> -\tgit --git-dir=repo1 log -1 --format=%s foo >actual &&\n> -\ttest_cmp expect actual\n> +\ttest_push_success upstream foo\n>  '\n>\n>  test_expect_success '\"upstream\" does not push on unconfigured remote' '\n> @@ -30,7 +61,7 @@ test_expect_success '\"upstream\" does not push on unconfigured remote' '\n>  \ttest_unconfig branch.master.remote &&\n>  \ttest_config push.default upstream &&\n>  \ttest_commit three &&\n> -\ttest_must_fail git push\n> +\ttest_push_failure upstream master\n>  '\n\n... and we can use --all not master here, right?\n\n>  test_expect_success '\"upstream\" does not push on unconfigured branch' '\n> @@ -39,7 +70,7 @@ test_expect_success '\"upstream\" does not push on unconfigured branch' '\n>  \ttest_unconfig branch.master.merge &&\n>  \ttest_config push.default upstream\n>  \ttest_commit four &&\n> -\ttest_must_fail git push\n> +\ttest_push_failure upstream master\n>  '\n\nSame here.\n\nThanks.\n"},{"id":"189882","messageId":"xmqqehrela20.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"1335170284-30768-5-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 4/7] push: introduce new push.default mode \"simple\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T15:52:55Z","receivedAt":"2012-04-23T15:52:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n\n> +* `simple` - like `upstream`, but refuses to push if the upstream\n> +  branch's name is different from the local one. This is the safest\n> +  option and is well-suited for beginners.\n\nLooks good.\n\n> diff --git a/builtin/push.c b/builtin/push.c\n> index 6936713..dae8306 100644\n> --- a/builtin/push.c\n> +++ b/builtin/push.c\n> @@ -76,7 +76,40 @@ static int push_url_of_remote(struct remote *remote, const char ***url_p)\n>  \treturn remote->url_nr;\n>  }\n>  \n> -static void setup_push_upstream(struct remote *remote)\n> +NORETURN die_push_simple(struct branch *branch, struct remote *remote) {\n\nNot static?\n\n> +\t/*\n> +\t * There's no point in using shorten_unambiguous_ref here,\n> +\t * as the ambiguity would be on the remote side, not what\n> +\t * we have locally. Plus, this is supposed to be the simple\n> +\t * mode. If the user is doing something crazy like setting\n> +\t * upstream to a non-branch, we should probably be showing\n> +\t * them the big ugly fully qualified ref.\n> +\t */\n> +\tconst char *short_up = skip_prefix(branch->merge[0]->src, \"refs/heads/\");\n\nUnless you change behaviour depending on NULL-ness of this variable\nlater in this code (and I do not think you do---this is only for a\nmessage string as far as I can see), I'd prefer to see that ?: you have\nat the use site here instead, i.e.\n\n\tif (!short_up)\n\t\tshort_up = branch->merge[0]->src;\n\nperhaps with s/short_up/dest_branch/ or something.\n\n> +\t/*\n> +\t * Don't show advice for people who explicitely set\n> +\t * push.default.\n> +\t */\n> +\tconst char *advice_maybe = \"\";\n> +\tif (push_default == PUSH_DEFAULT_UNSPECIFIED)\n> +\t\tadvice_maybe = _(\"\\n\"\n> +\t\t\t\t \"To choose either option permanently, \"\n> +\t\t\t\t \"see push.default in 'git help config'.\");\n\nNice.\n\n> +\tdie(_(\"The upstream branch of your current branch does not match\\n\"\n> +\t      \"the name of your current branch.  To push to the upstream branch\\n\"\n> +\t      \"on the remote, use\\n\"\n> +\t      \"\\n\"\n> +\t      \"    git push %s HEAD:%s\\n\"\n> +\t      \"\\n\"\n> +\t      \"To push to the branch of the same name on the remote, use\\n\"\n> +\t      \"\\n\"\n> +\t      \"    git push %s %s\\n\"\n> +\t      \"%s\"),\n> +\t    remote->name, short_up ? short_up : branch->merge[0]->src,\n> +\t    remote->name, branch->name, advice_maybe);\n> +}\n\n> @@ -103,6 +136,9 @@ static void setup_push_upstream(struct remote *remote)\n>  \t\t      \"your current branch '%s', without telling me what to push\\n\"\n>  \t\t      \"to update which remote branch.\"),\n>  \t\t    remote->name, branch->name);\n> +\tif (simple && strcmp(branch->refname, branch->merge[0]->src)) {\n> +\t\tdie_push_simple(branch, remote);\n> +\t}\n\nLose unnecessary {} pair, perhaps?\n\n> +\tgit --git-dir=repo1 log -1 --format=\"%h %s\" \"other-name\" >expect-other-name &&\n> +\ttest_push_success current master &&\n> +\tgit --git-dir=repo1 log -1 --format=\"%h %s\" \"other-name\" >actual-other-name &&\n> +\ttest_cmp expect-other-name actual-other-name\n\nHrm.\n\nThere is nothing wrong in the above part, but it shows taht it would be\nvery nice if test_push_success helper also encapsulated the \"make sure\nothers did not change\" logic.\n\nThanks for a pleasant read.\n"},{"id":"189883","messageId":"vpqobqil9ml.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"xmqqipgqlass.fsf@junio.mtv.corp.google.com","subject":"Re: [PATCH 3/7] t5528-push-default.sh: add helper functions","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-23T16:02:10Z","receivedAt":"2012-04-23T16:02:10Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Hmph.  How is $1 used in the above to make it compare between local and\n> remote?  Does the first one need to have \"$1\" before \" >expect\"?\n\nYes, good catch.\n\n>> +\ttest_must_fail git -c push.default=\"$1\" &&\n>\n> What subcommand does this run with one-shot override configuration?  Do\n> we need \" push\" before \" &&\"?\n\nRight.\n\nPlus the \"$1\" should have been \"$push_default\" since we just did a\nshift.\n\n*sigh* this was supposed not to be a draft :-(.\n\n>>  test_expect_success '\"upstream\" does not push on unconfigured remote' '\n>> @@ -30,7 +61,7 @@ test_expect_success '\"upstream\" does not push on unconfigured remote' '\n>>  \ttest_unconfig branch.master.remote &&\n>>  \ttest_config push.default upstream &&\n>>  \ttest_commit three &&\n>> -\ttest_must_fail git push\n>> +\ttest_push_failure upstream master\n>>  '\n>\n> ... and we can use --all not master here, right?\n\nActually, we can even use --all everywhere. And then, we don't even need\nthe second argument, and we can simplify greatly the function:\n\n# $1 = push.default value\n# check that push fails and does not modify any remote branch\ntest_push_failure () {\n\tgit --git-dir=repo1 log --no-walk --format='%h %s' --all >expect &&\n\ttest_must_fail git -c push.default=\"$1\" push &&\n\tgit --git-dir=repo1 log --no-walk --format='%h %s' --all >actual &&\n\ttest_cmp expect actual\n}\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189885","messageId":"vpqbomil9a1.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"xmqqehrela20.fsf@junio.mtv.corp.google.com","subject":"Re: [PATCH 4/7] push: introduce new push.default mode \"simple\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-23T16:09:42Z","receivedAt":"2012-04-23T16:09:42Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>> -static void setup_push_upstream(struct remote *remote)\n>> +NORETURN die_push_simple(struct branch *branch, struct remote *remote) {\n>\n> Not static?\n\nfixed.\n\n> Unless you change behaviour depending on NULL-ness of this variable\n> later in this code (and I do not think you do---this is only for a\n> message string as far as I can see), I'd prefer to see that ?: you have\n> at the use site here instead, i.e.\n>\n> \tif (!short_up)\n> \t\tshort_up = branch->merge[0]->src;\n\napplied.\n\n> perhaps with s/short_up/dest_branch/ or something.\n\nHmm, not really. It's a candidate destination branch, but we'll use the\nvariable only if the push fails because there is another candidate.\n\nI did s/short_up/short_upstream/ to make it clearer.\n\n>> +\tif (simple && strcmp(branch->refname, branch->merge[0]->src)) {\n>> +\t\tdie_push_simple(branch, remote);\n>> +\t}\n>\n> Lose unnecessary {} pair, perhaps?\n\nYes, removed.\n\n>> +\tgit --git-dir=repo1 log -1 --format=\"%h %s\" \"other-name\" >expect-other-name &&\n>> +\ttest_push_success current master &&\n>> +\tgit --git-dir=repo1 log -1 --format=\"%h %s\" \"other-name\" >actual-other-name &&\n>> +\ttest_cmp expect-other-name actual-other-name\n>\n> Hrm.\n>\n> There is nothing wrong in the above part, but it shows taht it would be\n> very nice if test_push_success helper also encapsulated the \"make sure\n> others did not change\" logic.\n\nThe issue is that one has to define \"others\", and it is different for\ncurrent and upstream so we'd have to add arguments to specify that to\ntest_push_success. I'd rather keep the helpers API simple, and\nspecial-case when needed as we did here.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189887","messageId":"xmqq8vhml8z7.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"vpqobqil9ml.fsf@bauges.imag.fr","subject":"Re: [PATCH 3/7] t5528-push-default.sh: add helper functions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T16:16:12Z","receivedAt":"2012-04-23T16:16:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n>> ... and we can use --all not master here, right?\n>\n> Actually, we can even use --all everywhere. And then, we don't even need\n> the second argument, and we can simplify greatly the function:\n\nThat did cross my mind but I suspected that the reason to have the\nargument was because you would want to use the helper also to test\n'matching' case where you want to make sure ones that the pusher does\nnot have are left alone.\n"},{"id":"189888","messageId":"vpqfwbuju8a.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"xmqq8vhml8z7.fsf@junio.mtv.corp.google.com","subject":"Re: [PATCH 3/7] t5528-push-default.sh: add helper functions","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-23T16:20:05Z","receivedAt":"2012-04-23T16:20:05Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>\n>>> ... and we can use --all not master here, right?\n>>\n>> Actually, we can even use --all everywhere. And then, we don't even need\n>> the second argument, and we can simplify greatly the function:\n>\n> That did cross my mind but I suspected that the reason to have the\n> argument was because you would want to use the helper also to test\n> 'matching' case where you want to make sure ones that the pusher does\n> not have are left alone.\n\nI did not add much for \"matching\" (that would be a separate topic, and\nmy Git time budget is getting short). But I think the simplicity of the\nnew function (both caller and callee side) is worth it, even if we later\nadd something more complex for the case of \"matching\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189895","messageId":"xmqqzka2jt64.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"xmqq8vhml8z7.fsf@junio.mtv.corp.google.com","subject":"Re: [PATCH 3/7] t5528-push-default.sh: add helper functions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T16:42:59Z","receivedAt":"2012-04-23T16:42:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>\n>>> ... and we can use --all not master here, right?\n>>\n>> Actually, we can even use --all everywhere. And then, we don't even need\n>> the second argument, and we can simplify greatly the function:\n>\n> That did cross my mind but I suspected that the reason to have the\n> argument was because you would want to use the helper also to test\n> 'matching' case where you want to make sure ones that the pusher does\n> not have are left alone.\n\nIn any case, here is the summary of my comments in patch form (I am not\nsquashing them myself).\n\n-- >8 --\nSubject: [PATCH 1/3] fixup! push: introduce new push.default mode \"simple\"\n\ncompilation fix; this should be static and needs type.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n builtin/push.c |    2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 7a845a8..913ac7a 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -76,7 +76,7 @@ static int push_url_of_remote(struct remote *remote, const char ***url_p)\n \treturn remote->url_nr;\n }\n \n-NORETURN die_push_simple(struct branch *branch, struct remote *remote) {\n+static NORETURN int die_push_simple(struct branch *branch, struct remote *remote) {\n \t/*\n \t * There's no point in using shorten_unambiguous_ref here,\n \t * as the ambiguity would be on the remote side, not what\n-- \n1.7.10.376.g4eb25\n"},{"id":"189896","messageId":"xmqqvckqjt1q.fsf_-_@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"xmqqzka2jt64.fsf@junio.mtv.corp.google.com","subject":"[PATCH 2/3] fixup! t5528-push-default.sh: add helper functions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T16:45:37Z","receivedAt":"2012-04-23T16:45:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Please eyeball the change to test_push_failure(); I think it is correct\nto use the same \"log --no-walk\" to prepare expect and actual, but I may\nhave missed something.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n t/t5528-push-default.sh |   10 +++++-----\n 1 file changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\nindex 43dec43..4a7d7fe 100755\n--- a/t/t5528-push-default.sh\n+++ b/t/t5528-push-default.sh\n@@ -16,7 +16,7 @@ test_expect_success 'setup bare remotes' '\n # $1 = local revision\n # $2 = remote revision (tested to be equal to the local one)\n check_pushed_commit () {\n-\tgit log -1 --format='%h %s' >expect &&\n+\tgit log -1 --format='%h %s' \"$1\" >expect &&\n \tgit --git-dir=repo1 log -1 --format='%h %s' \"$2\" >actual &&\n \ttest_cmp expect actual\n }\n@@ -39,11 +39,11 @@ test_push_failure () {\n \t\ttest_might_fail git --git-dir=repo1 \\\n \t\t\tlog --no-walk --format='%h %s' \"$@\" >expect\n \tfi &&\n-\ttest_must_fail git -c push.default=\"$1\" &&\n+\ttest_must_fail git -c push.default=\"$push_default\" push &&\n \tif test $# -gt 0\n \tthen\n \t\ttest_might_fail git --git-dir=repo1 \\\n-\t\t\tlog -1 --format='%h %s' \"$@\" >actual\n+\t\t\tlog --no-walk --format='%h %s' \"$@\" >actual\n \tfi &&\n \ttest_cmp expect actual\n }\n@@ -61,7 +61,7 @@ test_expect_success '\"upstream\" does not push on unconfigured remote' '\n \ttest_unconfig branch.master.remote &&\n \ttest_config push.default upstream &&\n \ttest_commit three &&\n-\ttest_push_failure upstream master\n+\ttest_push_failure upstream --all\n '\n \n test_expect_success '\"upstream\" does not push on unconfigured branch' '\n@@ -70,7 +70,7 @@ test_expect_success '\"upstream\" does not push on unconfigured branch' '\n \ttest_unconfig branch.master.merge &&\n \ttest_config push.default upstream\n \ttest_commit four &&\n-\ttest_push_failure upstream master\n+\ttest_push_failure upstream --all\n '\n \n test_expect_success '\"upstream\" does not push when remotes do not match' '\n-- \n1.7.10.376.g4eb25\n"},{"id":"189897","messageId":"xmqqr4vejsxl.fsf_-_@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"xmqqzka2jt64.fsf@junio.mtv.corp.google.com","subject":"[PATCH 3/3] push: suggested updates to push configuration documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T16:48:06Z","receivedAt":"2012-04-23T16:48:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This is only to show how the wording suggested in my review comment will\nread on top of the endpoint of your series, primarily for reviewing the\ncounterproposal (I didn't split this apart to apply in steps).\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n Documentation/config.txt |   30 +++++++++++++++---------------\n 1 file changed, 15 insertions(+), 15 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 696544e..f724fc6 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1681,29 +1681,29 @@ push.default::\n +\n * `nothing` - do not push anything.\n * `matching` - push all branches having the same name in both ends.\n-  This allows those who prepare all the branches into a publishable\n-  shape to push them out to a non-shared repository with a single\n-  command. This is well suited when pushing to a non-shared\n-  repository, but may give surprising results when used on a\n-  repository shared by multiple users, since locally stalled\n-  branches will attempt a non-fast forward push if other users\n-  updated the branch remotely. This is currently the default, but Git\n-  2.0 will change the default to `simple`.\n+  This is for those who prepare all the branches into a publishable\n+  shape and then push them out with a single command.  It is not\n+  appropriate for pushing into a repository shared by multiple users,\n+  since locally stalled branches will attempt a non-fast forward push\n+  if other users updated the branch.\n+  +\n+  This is currently the default, but Git 2.0 will change the default\n+  to `simple`.\n * `simple` - like `upstream`, but refuses to push if the upstream\n   branch's name is different from the local one. This is the safest\n   option and is well-suited for beginners. It will become the default\n   in Git 2.0.\n-* `upstream` - push the current branch to its upstream branch. See\n-  \"branch.<name>.merge\" for how to configure the upstream branch. This\n-  makes `git push` and `git pull` symmetrical in the sense that `push`\n-  will update the same remote ref as the one which is merged by\n-  `git pull`.\n+* `upstream` - push the current branch to its upstream branch.\n+  With this, `git push` will update the same remote ref as the one which\n+  is merged by `git pull`, making `push` and `pull` symmetrical.\n+  See \"branch.<name>.merge\" for how to configure the upstream branch.\n * `current` - push the current branch to a branch of the same name.\n   +\n   The `simple`, `current` and `upstream` modes are for those who want to\n   push out a single branch after finishing work, even when the other\n-  branches are not yet ready to be pushed out. They are safe when\n-  pushing to a shared repository.\n+  branches are not yet ready to be pushed out. If you are working with\n+  other people to push into the same shared repository, you would want\n+  to use one of these.\n \n rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\n-- \n1.7.10.376.g4eb25\n"},{"id":"189898","messageId":"vpqobqigzcx.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"vpqfwbuju8a.fsf@bauges.imag.fr","subject":"Re: [PATCH 3/7] t5528-push-default.sh: add helper functions","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-23T16:57:34Z","receivedAt":"2012-04-23T16:57:34Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>>\n>>>> ... and we can use --all not master here, right?\n>>>\n>>> Actually, we can even use --all everywhere. And then, we don't even need\n>>> the second argument, and we can simplify greatly the function:\n>>\n>> That did cross my mind but I suspected that the reason to have the\n>> argument was because you would want to use the helper also to test\n>> 'matching' case where you want to make sure ones that the pusher does\n>> not have are left alone.\n>\n> I did not add much for \"matching\" (that would be a separate topic, and\n> my Git time budget is getting short). But I think the simplicity of the\n> new function (both caller and callee side) is worth it, even if we later\n> add something more complex for the case of \"matching\".\n\nActually, there's a much stronger argument: we're talking about\ntest_push_failure (not success), so whatever the mode is, no branch\nshould be updated.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189899","messageId":"xmqqmx62jrxq.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"vpqobqigzcx.fsf@bauges.imag.fr","subject":"Re: [PATCH 3/7] t5528-push-default.sh: add helper functions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T17:09:37Z","receivedAt":"2012-04-23T17:09:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Actually, there's a much stronger argument: we're talking about\n> test_push_failure (not success), so whatever the mode is, no branch\n> should be updated.\n\nNot really.  When you have 'master' and 'side' (two branches), have\nupdated both but the remote side has only updated 'master', a push with\n'matching' behaves like this:\n\n$ git -c push.default=matching push\nCounting objects: 8, done.\nDelta compression using up to 12 threads.\nCompressing objects: 100% (2/2), done.\nWriting objects: 100% (6/6), 399 bytes, done.\nTotal 6 (delta 1), reused 0 (delta 0)\nUnpacking objects: 100% (6/6), done.\nTo /var/tmp/j/src\n   9e1359e..4d3f497  side -> side\n ! [rejected]        master -> master (non-fast-forward)\nerror: failed to push some refs to '/var/tmp/j/src'\nhint: Updates were rejected because a pushed branch tip is behind its remote\nhint: counterpart. Check out this branch and merge the remote changes\nhint: (e.g. 'git pull') before pushing again.\nhint: See the 'Note about fast-forwards' in 'git push --help' for details.\n$ echo $?\n1\n\nNotice the mention of \"some refs\" on the \"error:\" line.  'side' branch\nsuccessfully fast-forwards.\n"},{"id":"189907","messageId":"CB914FF3899C496F9E85E83B9532E055@PhilipOakley","threadId":"30086","inReplyTo":"1335170284-30768-2-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 1/7] Documentation: explain push.default option a bit more","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-04-23T19:00:25Z","receivedAt":"2012-04-23T19:00:25Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Matthieu Moy\" <Matthieu.Moy@imag.fr> Sent: Monday, April 23, 2012 \n9:37 AM\n> The previous documentation was explaining _what_ the options were doing,\n> but were of little help explaining _why_ a user should set his default to\n> either of the options.\n>\n> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n> ---\n> Documentation/config.txt |   22 ++++++++++++++++++----\n> 1 file changed, 18 insertions(+), 4 deletions(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index fb386ab..e38fab1 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1680,12 +1680,26 @@ push.default::\n>  line. Possible values are:\n> +\n> * `nothing` - do not push anything.\n> -* `matching` - push all matching branches.\n> -  All branches having the same name in both ends are considered to be\n> -  matching. This is the default.\n> -* `upstream` - push the current branch to its upstream branch.\n> +* `matching` - push all branches having the same name in both ends.\n> +  This allows those who prepare all the branches into a publishable\n> +  shape to push them out to a non-shared repository with a single\n> +  command. This is well suited when pushing to a non-shared\n> +  repository, but may give surprising results when used on a\n> +  repository shared by multiple users, since locally stalled\n> +  branches will attempt a non-fast forward push if other users\n> +  updated the branch remotely. This is the default.\n\nGiven the expected future change to 'simple' as the default, surely \"This is \ncurrently the default.\" give the hint toward that change.\n\n> +* `upstream` - push the current branch to its upstream branch. See\n> +  \"branch.<name>.merge\" for how to configure the upstream branch. This\n> +  makes `git push` and `git pull` symmetrical in the sense that `push`\n> +  will update the same remote ref as the one which is merged by\n> +  `git pull`.\n> * `tracking` - deprecated synonym for `upstream`.\n> * `current` - push the current branch to a branch of the same name.\n> +  +\n> +  The `current` and `upstream` modes are for those who want to\n> +  push out a single branch after finishing work, even when the other\n> +  branches are not yet ready to be pushed out. They are safe when\n> +  pushing to a shared repository.\n>\n> rebase.stat::\n>  Whether to show a diffstat of what changed upstream since the last\n> -- \n> 1.7.10.234.ge65dd.dirty\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n>\n> -----\n> No virus found in this message.\n> Checked by AVG - www.avg.com\n> Version: 2012.0.1913 / Virus Database: 2411/4953 - Release Date: 04/22/12\n> \n"},{"id":"189909","messageId":"xmqqwr56i7qk.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"CB914FF3899C496F9E85E83B9532E055@PhilipOakley","subject":"Re: [PATCH 1/7] Documentation: explain push.default option a bit more","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-23T19:11:15Z","receivedAt":"2012-04-23T19:11:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" <philipoakley@iee.org> writes:\n\n> From: \"Matthieu Moy\" <Matthieu.Moy@imag.fr> Sent: Monday, April 23,\n> 2012 9:37 AM\n>> The previous documentation was explaining _what_ the options were doing,\n>> but were of little help explaining _why_ a user should set his default to\n>> either of the options.\n>>\n>> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n>> ...\n>> +* `matching` - push all branches having the same name in both ends.\n>> + ...\n>> +  updated the branch remotely. This is the default.\n>\n> Given the expected future change to 'simple' as the default, surely\n> \"This is currently the default.\" give the hint toward that change.\n\nCorrect, and that is exactly why this patch does not say \"currently\".\n\nAs the proposed commit log message explains, this change is about\nclarifying what these options are and unrelated to \"future\" default\nchange at all at this step.\n"},{"id":"189914","messageId":"7D1315FBD9DC4581BB3C501A53E9E0F8@PhilipOakley","threadId":"30086","inReplyTo":"xmqqwr56i7qk.fsf@junio.mtv.corp.google.com","subject":"Re: [PATCH 1/7] Documentation: explain push.default option a bit more","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-04-23T21:01:26Z","receivedAt":"2012-04-23T21:01:26Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" <gitster@pobox.com>  Sent: Monday, April 23, 2012 \n8:11 PM\n> \"Philip Oakley\" <philipoakley@iee.org> writes:\n>\n>> From: \"Matthieu Moy\" <Matthieu.Moy@imag.fr> Sent: Monday, April 23,\n>> 2012 9:37 AM\n>>> The previous documentation was explaining _what_ the options were doing,\n>>> but were of little help explaining _why_ a user should set his default \n>>> to\n>>> either of the options.\n>>>\n>>> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n>>> ...\n>>> +* `matching` - push all branches having the same name in both ends.\n>>> + ...\n>>> +  updated the branch remotely. This is the default.\n>>\n>> Given the expected future change to 'simple' as the default, surely\n>> \"This is currently the default.\" give the hint toward that change.\n>\n> Correct, and that is exactly why this patch does not say \"currently\".\n>\n> As the proposed commit log message explains, this change is about\n> clarifying what these options are and unrelated to \"future\" default\n> change at all at this step.\n>\n\nMy mistake. Sorry for the noise / misunderstanding. I now see that [PATCH \n6/7] has the change. \n"},{"id":"189940","messageId":"1335253806-9059-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335170284-30768-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 0/7 v4] push.default upcomming change","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-24T07:49:59Z","receivedAt":"2012-04-24T07:49:59Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"This version should address all the comments from Junio, except that I\nwent for my simple one-argument test_push_failure (we don't need the\ncomplex one for now, and I'm not sure the complex one will be good\nenough when we want to test 'matching'---for example, we may want to\nparse the output of 'git push').\n\nClemens Buchacher (1):\n  t5570: use explicit push refspec\n\nMatthieu Moy (6):\n  Documentation: explain push.default option a bit more\n  Undocument deprecated alias 'push.default=tracking'\n  t5528-push-default.sh: add helper functions\n  push: introduce new push.default mode \"simple\"\n  push: document the future default change for push.default (matching\n    -> simple)\n  push: start warning upcoming default change for push.default\n\n Documentation/config.txt |   26 +++++++++++++---\n builtin/push.c           |   73 ++++++++++++++++++++++++++++++++++++++++---\n cache.h                  |    1 +\n config.c                 |    6 ++--\n t/t5528-push-default.sh  |   78 +++++++++++++++++++++++++++++++++++++++++-----\n t/t5570-git-daemon.sh    |   30 +++++++++---------\n 6 files changed, 181 insertions(+), 33 deletions(-)\n\n-- \n1.7.10.234.g365b0\n"},{"id":"189942","messageId":"1335253806-9059-2-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335253806-9059-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 1/7] Documentation: explain push.default option a bit more","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-24T07:50:00Z","receivedAt":"2012-04-24T07:50:00Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"The previous documentation was explaining _what_ the options were doing,\nbut were of little help explaining _why_ a user should set his default to\neither of the options.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\nShould match exactly Junio's proposal. I like the wording.\n\n Documentation/config.txt |   18 +++++++++++++++---\n 1 file changed, 15 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex fb386ab..5f14871 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1680,12 +1680,24 @@ push.default::\n \tline. Possible values are:\n +\n * `nothing` - do not push anything.\n-* `matching` - push all matching branches.\n-  All branches having the same name in both ends are considered to be\n-  matching. This is the default.\n+* `matching` - push all branches having the same name in both ends.\n+  This is for those who prepare all the branches into a publishable\n+  shape and then push them out with a single command.  It is not\n+  appropriate for pushing into a repository shared by multiple users,\n+  since locally stalled branches will attempt a non-fast forward push\n+  if other users updated the branch.  This is the default.\n * `upstream` - push the current branch to its upstream branch.\n+  With this, `git push` will update the same remote ref as the one which\n+  is merged by `git pull`, making `push` and `pull` symmetrical.\n+  See \"branch.<name>.merge\" for how to configure the upstream branch.\n * `tracking` - deprecated synonym for `upstream`.\n * `current` - push the current branch to a branch of the same name.\n+  +\n+  The `current` and `upstream` modes are for those who want to\n+  push out a single branch after finishing work, even when the other\n+  branches are not yet ready to be pushed out. If you are working with\n+  other people to push into the same shared repository, you would want\n+  to use one of these.\n \n rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\n-- \n1.7.10.234.g365b0\n"},{"id":"189941","messageId":"1335253806-9059-3-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335253806-9059-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-24T07:50:01Z","receivedAt":"2012-04-24T07:50:01Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,\npush.default: Rename 'tracking' to 'upstream'), so it's OK to remove it\nfrom documentation (even though it's still supported) to make the\nexplanations more readable.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n Documentation/config.txt |    1 -\n 1 file changed, 1 deletion(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 5f14871..9617c53 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1690,7 +1690,6 @@ push.default::\n   With this, `git push` will update the same remote ref as the one which\n   is merged by `git pull`, making `push` and `pull` symmetrical.\n   See \"branch.<name>.merge\" for how to configure the upstream branch.\n-* `tracking` - deprecated synonym for `upstream`.\n * `current` - push the current branch to a branch of the same name.\n   +\n   The `current` and `upstream` modes are for those who want to\n-- \n1.7.10.234.g365b0\n"},{"id":"189946","messageId":"1335253806-9059-4-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335253806-9059-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 3/7] t5528-push-default.sh: add helper functions","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-24T07:50:02Z","receivedAt":"2012-04-24T07:50:02Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n t/t5528-push-default.sh |   34 +++++++++++++++++++++++++++-------\n 1 file changed, 27 insertions(+), 7 deletions(-)\n\ndiff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\nindex c334c51..99e5519 100755\n--- a/t/t5528-push-default.sh\n+++ b/t/t5528-push-default.sh\n@@ -13,16 +13,36 @@ test_expect_success 'setup bare remotes' '\n \tgit push parent2 HEAD\n '\n \n+# $1 = local revision\n+# $2 = remote revision (tested to be equal to the local one)\n+check_pushed_commit () {\n+\tgit log -1 --format='%h %s' \"$1\" >expect &&\n+\tgit --git-dir=repo1 log -1 --format='%h %s' \"$2\" >actual &&\n+\ttest_cmp expect actual\n+}\n+\n+# $1 = push.default value\n+# $2 = expected target branch for the push\n+test_push_success () {\n+\tgit -c push.default=\"$1\" push &&\n+\tcheck_pushed_commit HEAD \"$2\"\n+}\n+\n+# $1 = push.default value\n+# check that push fails and does not modify any remote branch\n+test_push_failure () {\n+\tgit --git-dir=repo1 log --no-walk --format='%h %s' --all >expect &&\n+\ttest_must_fail git -c push.default=\"$1\" push &&\n+\tgit --git-dir=repo1 log --no-walk --format='%h %s' --all >actual &&\n+\ttest_cmp expect actual\n+}\n+\n test_expect_success '\"upstream\" pushes to configured upstream' '\n \tgit checkout master &&\n \ttest_config branch.master.remote parent1 &&\n \ttest_config branch.master.merge refs/heads/foo &&\n-\ttest_config push.default upstream &&\n \ttest_commit two &&\n-\tgit push &&\n-\techo two >expect &&\n-\tgit --git-dir=repo1 log -1 --format=%s foo >actual &&\n-\ttest_cmp expect actual\n+\ttest_push_success upstream foo\n '\n \n test_expect_success '\"upstream\" does not push on unconfigured remote' '\n@@ -30,7 +50,7 @@ test_expect_success '\"upstream\" does not push on unconfigured remote' '\n \ttest_unconfig branch.master.remote &&\n \ttest_config push.default upstream &&\n \ttest_commit three &&\n-\ttest_must_fail git push\n+\ttest_push_failure upstream\n '\n \n test_expect_success '\"upstream\" does not push on unconfigured branch' '\n@@ -39,7 +59,7 @@ test_expect_success '\"upstream\" does not push on unconfigured branch' '\n \ttest_unconfig branch.master.merge &&\n \ttest_config push.default upstream\n \ttest_commit four &&\n-\ttest_must_fail git push\n+\ttest_push_failure upstream\n '\n \n test_expect_success '\"upstream\" does not push when remotes do not match' '\n-- \n1.7.10.234.g365b0\n"},{"id":"189945","messageId":"1335253806-9059-5-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335253806-9059-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 4/7] push: introduce new push.default mode \"simple\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-24T07:50:03Z","receivedAt":"2012-04-24T07:50:03Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"When calling \"git push\" without argument, we want to allow Git to do\nsomething simple to explain and safe. push.default=matching is unsafe\nwhen used to push to shared repositories, and hard to explain to\nbeginners in some contexts. It is debatable whether 'upstream' or\n'current' is the safest or the easiest to explain, so introduce a new\nmode called 'simple' that is the intersection of them: push to the\nupstream branch, but only if it has the same name remotely. If not, give\nan error that suggests the right command to push explicitely to\n'upstream' or 'current'.\n\nA question is whether to allow pushing when no upstream is configured. An\nargument in favor of allowing the push is that it makes the new mode work\nin more cases. On the other hand, refusing to push when no upstream is\nconfigured encourages the user to set the upstream, which will be\nbeneficial on the next pull. Lacking better argument, we chose to deny\nthe push, because it will be easier to change in the future if someone\nshows us wrong.\n\nOriginal-patch-by: Jeff King <peff@peff.net>\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n Documentation/config.txt |    5 ++++-\n builtin/push.c           |   46 ++++++++++++++++++++++++++++++++++++++++++++--\n cache.h                  |    1 +\n config.c                 |    6 ++++--\n t/t5528-push-default.sh  |   44 ++++++++++++++++++++++++++++++++++++++++++++\n 5 files changed, 97 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 9617c53..7f5ad1c 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1686,13 +1686,16 @@ push.default::\n   appropriate for pushing into a repository shared by multiple users,\n   since locally stalled branches will attempt a non-fast forward push\n   if other users updated the branch.  This is the default.\n+* `simple` - like `upstream`, but refuses to push if the upstream\n+  branch's name is different from the local one. This is the safest\n+  option and is well-suited for beginners.\n * `upstream` - push the current branch to its upstream branch.\n   With this, `git push` will update the same remote ref as the one which\n   is merged by `git pull`, making `push` and `pull` symmetrical.\n   See \"branch.<name>.merge\" for how to configure the upstream branch.\n * `current` - push the current branch to a branch of the same name.\n   +\n-  The `current` and `upstream` modes are for those who want to\n+  The `simple`, `current` and `upstream` modes are for those who want to\n   push out a single branch after finishing work, even when the other\n   branches are not yet ready to be pushed out. If you are working with\n   other people to push into the same shared repository, you would want\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 6936713..8e663db 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -76,7 +76,43 @@ static int push_url_of_remote(struct remote *remote, const char ***url_p)\n \treturn remote->url_nr;\n }\n \n-static void setup_push_upstream(struct remote *remote)\n+static NORETURN int die_push_simple(struct branch *branch, struct remote *remote) {\n+\t/*\n+\t * There's no point in using shorten_unambiguous_ref here,\n+\t * as the ambiguity would be on the remote side, not what\n+\t * we have locally. Plus, this is supposed to be the simple\n+\t * mode. If the user is doing something crazy like setting\n+\t * upstream to a non-branch, we should probably be showing\n+\t * them the big ugly fully qualified ref.\n+\t */\n+\tconst char *short_upstream =\n+\t\tskip_prefix(branch->merge[0]->src, \"refs/heads/\");\n+\tif (!short_upstream)\n+\t\tshort_upstream = branch->merge[0]->src;\n+\t/*\n+\t * Don't show advice for people who explicitely set\n+\t * push.default.\n+\t */\n+\tconst char *advice_maybe = \"\";\n+\tif (push_default == PUSH_DEFAULT_UNSPECIFIED)\n+\t\tadvice_maybe = _(\"\\n\"\n+\t\t\t\t \"To choose either option permanently, \"\n+\t\t\t\t \"see push.default in 'git help config'.\");\n+\tdie(_(\"The upstream branch of your current branch does not match\\n\"\n+\t      \"the name of your current branch.  To push to the upstream branch\\n\"\n+\t      \"on the remote, use\\n\"\n+\t      \"\\n\"\n+\t      \"    git push %s HEAD:%s\\n\"\n+\t      \"\\n\"\n+\t      \"To push to the branch of the same name on the remote, use\\n\"\n+\t      \"\\n\"\n+\t      \"    git push %s %s\\n\"\n+\t      \"%s\"),\n+\t    remote->name, short_upstream,\n+\t    remote->name, branch->name, advice_maybe);\n+}\n+\n+static void setup_push_upstream(struct remote *remote, int simple)\n {\n \tstruct strbuf refspec = STRBUF_INIT;\n \tstruct branch *branch = branch_get(NULL);\n@@ -103,6 +139,8 @@ static void setup_push_upstream(struct remote *remote)\n \t\t      \"your current branch '%s', without telling me what to push\\n\"\n \t\t      \"to update which remote branch.\"),\n \t\t    remote->name, branch->name);\n+\tif (simple && strcmp(branch->refname, branch->merge[0]->src))\n+\t\tdie_push_simple(branch, remote);\n \n \tstrbuf_addf(&refspec, \"%s:%s\", branch->name, branch->merge[0]->src);\n \tadd_refspec(refspec.buf);\n@@ -119,8 +157,12 @@ static void setup_default_push_refspecs(struct remote *remote)\n \t\tadd_refspec(\":\");\n \t\tbreak;\n \n+\tcase PUSH_DEFAULT_SIMPLE:\n+\t\tsetup_push_upstream(remote, 1);\n+\t\tbreak;\n+\n \tcase PUSH_DEFAULT_UPSTREAM:\n-\t\tsetup_push_upstream(remote);\n+\t\tsetup_push_upstream(remote, 0);\n \t\tbreak;\n \n \tcase PUSH_DEFAULT_CURRENT:\ndiff --git a/cache.h b/cache.h\nindex 5bf59ff..b60d490 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -624,6 +624,7 @@ enum rebase_setup_type {\n enum push_default_type {\n \tPUSH_DEFAULT_NOTHING = 0,\n \tPUSH_DEFAULT_MATCHING,\n+\tPUSH_DEFAULT_SIMPLE,\n \tPUSH_DEFAULT_UPSTREAM,\n \tPUSH_DEFAULT_CURRENT,\n \tPUSH_DEFAULT_UNSPECIFIED\ndiff --git a/config.c b/config.c\nindex 68d3294..bfe0c79 100644\n--- a/config.c\n+++ b/config.c\n@@ -829,6 +829,8 @@ static int git_default_push_config(const char *var, const char *value)\n \t\t\tpush_default = PUSH_DEFAULT_NOTHING;\n \t\telse if (!strcmp(value, \"matching\"))\n \t\t\tpush_default = PUSH_DEFAULT_MATCHING;\n+\t\telse if (!strcmp(value, \"simple\"))\n+\t\t\tpush_default = PUSH_DEFAULT_SIMPLE;\n \t\telse if (!strcmp(value, \"upstream\"))\n \t\t\tpush_default = PUSH_DEFAULT_UPSTREAM;\n \t\telse if (!strcmp(value, \"tracking\")) /* deprecated */\n@@ -837,8 +839,8 @@ static int git_default_push_config(const char *var, const char *value)\n \t\t\tpush_default = PUSH_DEFAULT_CURRENT;\n \t\telse {\n \t\t\terror(\"Malformed value for %s: %s\", var, value);\n-\t\t\treturn error(\"Must be one of nothing, matching, \"\n-\t\t\t\t     \"tracking or current.\");\n+\t\t\treturn error(\"Must be one of nothing, matching, simple, \"\n+\t\t\t\t     \"upstream or current.\");\n \t\t}\n \t\treturn 0;\n \t}\ndiff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\nindex 99e5519..4736da8 100755\n--- a/t/t5528-push-default.sh\n+++ b/t/t5528-push-default.sh\n@@ -71,4 +71,48 @@ test_expect_success '\"upstream\" does not push when remotes do not match' '\n \ttest_must_fail git push parent2\n '\n \n+test_expect_success 'push from/to new branch with upstream, matching and simple' '\n+\tgit checkout -b new-branch &&\n+\ttest_push_failure simple &&\n+\ttest_push_failure matching &&\n+\ttest_push_failure upstream\n+'\n+\n+test_expect_success 'push from/to new branch with current creates remote branch' '\n+\ttest_config branch.new-branch.remote repo1 &&\n+\tgit checkout new-branch &&\n+\ttest_push_success current new-branch\n+'\n+\n+test_expect_success 'push to existing branch, with no upstream configured' '\n+\ttest_config branch.master.remote repo1 &&\n+\tgit checkout master &&\n+\ttest_push_failure simple &&\n+\ttest_push_failure upstream\n+'\n+\n+test_expect_success 'push to existing branch, upstream configured with same name' '\n+\ttest_config branch.master.remote repo1 &&\n+\ttest_config branch.master.merge refs/heads/master &&\n+\tgit checkout master &&\n+\ttest_commit six &&\n+\ttest_push_success upstream master &&\n+\ttest_commit seven &&\n+\ttest_push_success simple master\n+'\n+\n+test_expect_success 'push to existing branch, upstream configured with different name' '\n+\ttest_config branch.master.remote repo1 &&\n+\ttest_config branch.master.merge refs/heads/other-name &&\n+\tgit checkout master &&\n+\ttest_commit eight &&\n+\ttest_push_success upstream other-name &&\n+\ttest_commit nine &&\n+\ttest_push_failure simple &&\n+\tgit --git-dir=repo1 log -1 --format=\"%h %s\" \"other-name\" >expect-other-name &&\n+\ttest_push_success current master &&\n+\tgit --git-dir=repo1 log -1 --format=\"%h %s\" \"other-name\" >actual-other-name &&\n+\ttest_cmp expect-other-name actual-other-name\n+'\n+\n test_done\n-- \n1.7.10.234.g365b0\n"},{"id":"189947","messageId":"1335253806-9059-6-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335253806-9059-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 5/7] t5570: use explicit push refspec","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-24T07:50:04Z","receivedAt":"2012-04-24T07:50:04Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"From: Clemens Buchacher <drizzd@aon.at>\n\nThe default mode for push without arguments will change. Some warnings\nare about to be enabled for such use, which causes some t5570 tests to\nfail because they do not expect this output.\n\nFix this by passing an explicit refspec to git push. To that end, change\nthe calling conventions of test_remote_error in order to accomodate\nextra command arguments.\n\nSigned-off-by: Clemens Buchacher <drizzd@aon.at>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n t/t5570-git-daemon.sh |   30 ++++++++++++++----------------\n 1 file changed, 14 insertions(+), 16 deletions(-)\n\ndiff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh\nindex 7cbc999..a3a4e47 100755\n--- a/t/t5570-git-daemon.sh\n+++ b/t/t5570-git-daemon.sh\n@@ -103,14 +103,12 @@ test_remote_error()\n \t\tesac\n \tdone\n \n-\tif test $# -ne 3\n-\tthen\n-\t\terror \"invalid number of arguments\"\n-\tfi\n-\n+\tmsg=$1\n+\tshift\n \tcmd=$1\n-\trepo=$2\n-\tmsg=$3\n+\tshift\n+\trepo=$1\n+\tshift || error \"invalid number of arguments\"\n \n \tif test -x \"$GIT_DAEMON_DOCUMENT_ROOT_PATH/$repo\"\n \tthen\n@@ -122,7 +120,7 @@ test_remote_error()\n \t\tfi\n \tfi\n \n-\ttest_must_fail git \"$cmd\" \"$GIT_DAEMON_URL/$repo\" 2>output &&\n+\ttest_must_fail git \"$cmd\" \"$GIT_DAEMON_URL/$repo\" \"$@\" 2>output &&\n \techo \"fatal: remote error: $msg: /$repo\" >expect &&\n \ttest_cmp expect output\n \tret=$?\n@@ -131,18 +129,18 @@ test_remote_error()\n }\n \n msg=\"access denied or repository not exported\"\n-test_expect_success 'clone non-existent' \"test_remote_error    clone nowhere.git '$msg'\"\n-test_expect_success 'push disabled'      \"test_remote_error    push  repo.git    '$msg'\"\n-test_expect_success 'read access denied' \"test_remote_error -x fetch repo.git    '$msg'\"\n-test_expect_success 'not exported'       \"test_remote_error -n fetch repo.git    '$msg'\"\n+test_expect_success 'clone non-existent' \"test_remote_error    '$msg' clone nowhere.git    \"\n+test_expect_success 'push disabled'      \"test_remote_error    '$msg' push  repo.git master\"\n+test_expect_success 'read access denied' \"test_remote_error -x '$msg' fetch repo.git       \"\n+test_expect_success 'not exported'       \"test_remote_error -n '$msg' fetch repo.git       \"\n \n stop_git_daemon\n start_git_daemon --informative-errors\n \n-test_expect_success 'clone non-existent' \"test_remote_error    clone nowhere.git 'no such repository'\"\n-test_expect_success 'push disabled'      \"test_remote_error    push  repo.git    'service not enabled'\"\n-test_expect_success 'read access denied' \"test_remote_error -x fetch repo.git    'no such repository'\"\n-test_expect_success 'not exported'       \"test_remote_error -n fetch repo.git    'repository not exported'\"\n+test_expect_success 'clone non-existent' \"test_remote_error    'no such repository'      clone nowhere.git    \"\n+test_expect_success 'push disabled'      \"test_remote_error    'service not enabled'     push  repo.git master\"\n+test_expect_success 'read access denied' \"test_remote_error -x 'no such repository'      fetch repo.git       \"\n+test_expect_success 'not exported'       \"test_remote_error -n 'repository not exported' fetch repo.git       \"\n \n stop_git_daemon\n test_done\n-- \n1.7.10.234.g365b0\n"},{"id":"189943","messageId":"1335253806-9059-7-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335253806-9059-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 6/7] push: document the future default change for push.default (matching -> simple)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-24T07:50:05Z","receivedAt":"2012-04-24T07:50:05Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"It is too early to start warning loudly about the future default change\nin favor of 'simple', since many users use different versions of Git, and\nwould be harmed if we advised them to explicitely set\n'push.default=simple' when using old versions of Git.\n\nStill, we want to document the upcomming change so that:\n\n* Users who may be affected by the change get one more chance to know it\n  in advance.\n\n* We actually commit to changing the default, and avoid repeating past\n  errors.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n---\n Documentation/config.txt |    8 ++++++--\n 1 file changed, 6 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 7f5ad1c..f724fc6 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1685,10 +1685,14 @@ push.default::\n   shape and then push them out with a single command.  It is not\n   appropriate for pushing into a repository shared by multiple users,\n   since locally stalled branches will attempt a non-fast forward push\n-  if other users updated the branch.  This is the default.\n+  if other users updated the branch.\n+  +\n+  This is currently the default, but Git 2.0 will change the default\n+  to `simple`.\n * `simple` - like `upstream`, but refuses to push if the upstream\n   branch's name is different from the local one. This is the safest\n-  option and is well-suited for beginners.\n+  option and is well-suited for beginners. It will become the default\n+  in Git 2.0.\n * `upstream` - push the current branch to its upstream branch.\n   With this, `git push` will update the same remote ref as the one which\n   is merged by `git pull`, making `push` and `pull` symmetrical.\n-- \n1.7.10.234.g365b0\n"},{"id":"189944","messageId":"1335253806-9059-8-git-send-email-Matthieu.Moy@imag.fr","threadId":"30086","inReplyTo":"1335253806-9059-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 7/7] push: start warning upcoming default change for push.default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2012-04-24T07:50:06Z","receivedAt":"2012-04-24T07:50:06Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"In preparation for flipping the default to the \"simple\" mode from\nthe \"matching\" mode that is the historical default, start warning\nusers when they rely on unconfigured \"git push\" to default to the\n\"matching\" mode.\n\nAlso, advertise for 'simple' where 'current' and 'upstream' are advised.\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n builtin/push.c |   27 +++++++++++++++++++++++++--\n 1 file changed, 25 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 8e663db..be4525a 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -146,12 +146,35 @@ static void setup_push_upstream(struct remote *remote, int simple)\n \tadd_refspec(refspec.buf);\n }\n \n+static char warn_unspecified_push_default_msg[] =\n+N_(\"push.default is unset; its implicit value is changing in\\n\"\n+   \"Git 2.0 from 'matching' to 'simple'. To squelch this message\\n\"\n+   \"and maintain the current behavior after the default changes, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default matching\\n\"\n+   \"\\n\"\n+   \"To squelch this message and adopt the new behavior now, use:\\n\"\n+   \"\\n\"\n+   \"  git config --global push.default simple\\n\"\n+   \"\\n\"\n+   \"See 'git help config' and search for 'push.default' for further information.\");\n+\n+static void warn_unspecified_push_default_configuration(void)\n+{\n+\tstatic int warn_once;\n+\n+\tif (warn_once++)\n+\t\treturn;\n+\twarning(\"%s\\n\", _(warn_unspecified_push_default_msg));\n+}\n+\n static void setup_default_push_refspecs(struct remote *remote)\n {\n \tswitch (push_default) {\n \tdefault:\n \tcase PUSH_DEFAULT_UNSPECIFIED:\n \t\tdefault_matching_used = 1;\n+\t\twarn_unspecified_push_default_configuration();\n \t\t/* fallthru */\n \tcase PUSH_DEFAULT_MATCHING:\n \t\tadd_refspec(\":\");\n@@ -185,8 +208,8 @@ static const char message_advice_pull_before_push[] =\n static const char message_advice_use_upstream[] =\n \tN_(\"Updates were rejected because a pushed branch tip is behind its remote\\n\"\n \t   \"counterpart. If you did not intend to push that branch, you may want to\\n\"\n-\t   \"specify branches to push or set the 'push.default' configuration\\n\"\n-\t   \"variable to 'current' or 'upstream' to push only the current branch.\");\n+\t   \"specify branches to push or set the 'push.default' configuration variable\\n\"\n+\t   \"to 'simple', 'current' or 'upstream' to push only the current branch.\");\n \n static const char message_advice_checkout_pull_push[] =\n \tN_(\"Updates were rejected because a pushed branch tip is behind its remote\\n\"\n-- \n1.7.10.234.g365b0\n"},{"id":"189984","messageId":"xmqq1undgcad.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"1335253806-9059-1-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 0/7 v4] push.default upcomming change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-24T19:28:10Z","receivedAt":"2012-04-24T19:28:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n\n> This version should address all the comments from Junio, except that I\n> went for my simple one-argument test_push_failure (we don't need the\n> complex one for now, and I'm not sure the complex one will be good\n> enough when we want to test 'matching'---for example, we may want to\n> parse the output of 'git push').\n\nFine by me, and the result looks good.\n\nI'll queue everything before the final one, with a single readability\nupdate (attached below) on top, on mm/simple-push topic. And then the\nfinal one will be queued on a separate mm/push/default-switch-warning\ntopic that is forked from the former.\n\nThanks for working on this.  With acks from others I'm hoping that we\ncan merge the \"simple\" to 'next' soonish.\n\n-- >8 --\nSubject: [PATCH] push.default doc: explain simple after upstream\n\nAs the \"simple\" mode is described in terms of what \"upstream\" does,\nswap the order of these two entries so that the reader sees \"upstream\"\nfirst and then reads \"simple\" with the knowledge of what \"upstream\"\ndoes.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n Documentation/config.txt |    8 ++++----\n 1 file changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex f724fc6..6a4c130 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1689,14 +1689,14 @@ push.default::\n   +\n   This is currently the default, but Git 2.0 will change the default\n   to `simple`.\n-* `simple` - like `upstream`, but refuses to push if the upstream\n-  branch's name is different from the local one. This is the safest\n-  option and is well-suited for beginners. It will become the default\n-  in Git 2.0.\n * `upstream` - push the current branch to its upstream branch.\n   With this, `git push` will update the same remote ref as the one which\n   is merged by `git pull`, making `push` and `pull` symmetrical.\n   See \"branch.<name>.merge\" for how to configure the upstream branch.\n+* `simple` - like `upstream`, but refuses to push if the upstream\n+  branch's name is different from the local one. This is the safest\n+  option and is well-suited for beginners. It will become the default\n+  in Git 2.0.\n * `current` - push the current branch to a branch of the same name.\n   +\n   The `simple`, `current` and `upstream` modes are for those who want to\n-- \n1.7.10.433.g8de07\n"},{"id":"190041","messageId":"xmqqd36weewk.fsf@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"1335253806-9059-5-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 4/7] push: introduce new push.default mode \"simple\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-25T01:53:14Z","receivedAt":"2012-04-25T01:53:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n\n> diff --git a/builtin/push.c b/builtin/push.c\n> index 6936713..8e663db 100644\n> --- a/builtin/push.c\n> +++ b/builtin/push.c\n> @@ -76,7 +76,43 @@ static int push_url_of_remote(struct remote *remote, const char ***url_p)\n>  \treturn remote->url_nr;\n>  }\n>  \n> -static void setup_push_upstream(struct remote *remote)\n> +static NORETURN int die_push_simple(struct branch *branch, struct remote *remote) {\n> +\t/*\n> +\t * There's no point in using shorten_unambiguous_ref here,\n> +\t * as the ambiguity would be on the remote side, not what\n> +\t * we have locally. Plus, this is supposed to be the simple\n> +\t * mode. If the user is doing something crazy like setting\n> +\t * upstream to a non-branch, we should probably be showing\n> +\t * them the big ugly fully qualified ref.\n> +\t */\n> +\tconst char *short_upstream =\n> +\t\tskip_prefix(branch->merge[0]->src, \"refs/heads/\");\n> +\tif (!short_upstream)\n> +\t\tshort_upstream = branch->merge[0]->src;\n> +\t/*\n> +\t * Don't show advice for people who explicitely set\n> +\t * push.default.\n> +\t */\n> +\tconst char *advice_maybe = \"\";\n\nI've amended this to avoid decl-after-stmt.\n\nI think the series is ready for 'next' but I'll wait for a few days or\nuntil I see acks from trusted others, whichever comes sooner.\n\nThanks.\n"},{"id":"190056","messageId":"vpqsjfsulay.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"xmqqd36weewk.fsf@junio.mtv.corp.google.com","subject":"Re: [PATCH 4/7] push: introduce new push.default mode \"simple\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-25T11:01:57Z","receivedAt":"2012-04-25T11:01:57Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>> +\tif (!short_upstream)\n>> +\t\tshort_upstream = branch->merge[0]->src;\n>> +\t/*\n>> +\t * Don't show advice for people who explicitely set\n>> +\t * push.default.\n>> +\t */\n>> +\tconst char *advice_maybe = \"\";\n>\n> I've amended this to avoid decl-after-stmt.\n\nOops, right, I didn't notice the advice_maybe was a declaration.\n\nThanks for the fix.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"190095","messageId":"xmqqpqav9hdl.fsf_-_@junio.mtv.corp.google.com","threadId":"30086","inReplyTo":"1334876234-20077-4-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH] t5541: warning message is given even with --quiet","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-26T05:44:38Z","receivedAt":"2012-04-26T05:44:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Explicitly set push.default to matching to avoid the warning message;\nthe test wants to verify there is no post-push report when --quiet is\ngiven, and this message interferes with it.\n\nThis change is *iffy*, not in the sense that it breaks the test it\ntouches, but because it is unclear if the output should be given when\nthe user explicitly asked --quiet.\n\nOn one hand, --quiet is a request to be \"quiet\", but on the other hand,\nthis warning is meant to be shown in the face in large flashing red\nletters no matter what the user says, so...\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n t/t5541-http-push.sh |    5 ++++-\n 1 file changed, 4 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh\nindex 5b170be..07fa199 100755\n--- a/t/t5541-http-push.sh\n+++ b/t/t5541-http-push.sh\n@@ -64,7 +64,10 @@ test_expect_success 'no empty path components' '\n \n test_expect_success 'clone remote repository' '\n \trm -rf test_repo_clone &&\n-\tgit clone $HTTPD_URL/smart/test_repo.git test_repo_clone\n+\tgit clone $HTTPD_URL/smart/test_repo.git test_repo_clone &&\n+\t(\n+\t\tcd test_repo_clone && git config push.default matching\n+\t)\n '\n \n test_expect_success 'push to remote repository (standard)' '\n-- \n1.7.10.475.g8b959\n"},{"id":"190098","messageId":"vpqpqavf1hs.fsf@bauges.imag.fr","threadId":"30086","inReplyTo":"xmqqpqav9hdl.fsf_-_@junio.mtv.corp.google.com","subject":"Re: [PATCH] t5541: warning message is given even with --quiet","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-26T06:31:11Z","receivedAt":"2012-04-26T06:31:11Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> On one hand, --quiet is a request to be \"quiet\", but on the other hand,\n> this warning is meant to be shown in the face in large flashing red\n> letters no matter what the user says, so...\n\nI'd say it's OK to show the warning with --quiet. Users will normally\nset the config option in ~/.gitconfig and forget about it, both in\ninteractive use and in scripts.\n\nSo,\n\n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\nAcked-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"208367","messageId":"CACBZZX552fnD+u9Zp-BhqDyYWN+OiyvCyub-xjMZ-_GXCG-vQA@mail.gmail.com","threadId":"30086","inReplyTo":"1335170284-30768-3-git-send-email-Matthieu.Moy@imag.fr","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2013-01-31T17:10:59Z","receivedAt":"2013-01-31T17:10:59Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:\n> It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,\n> push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it\n> from documentation (even though it's still supported) to make the\n> explanations more readable.\n\nI don't think this was a good move for the documentation. Now every\ntime I find an old repo with \"push.default=tracking\" I end up\nwondering what it was a synonym for again, and other users who don't\nknow what it does will just assume it's an invalid value or something.\n\nWe can't treat existing config values we still support as any other\ndeprecated feature. They still exist in files we have no control over,\nand in people's brains who are reading \"man git-config\" trying to\nremember what it meant.\n\n> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n> ---\n> Feel free to squash into previous one if needed.\n>\n>  Documentation/config.txt |    1 -\n>  1 file changed, 1 deletion(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index e38fab1..ddf6043 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1693,7 +1693,6 @@ push.default::\n>    makes `git push` and `git pull` symmetrical in the sense that `push`\n>    will update the same remote ref as the one which is merged by\n>    `git pull`.\n> -* `tracking` - deprecated synonym for `upstream`.\n>  * `current` - push the current branch to a branch of the same name.\n>    +\n>    The `current` and `upstream` modes are for those who want to\n> --\n> 1.7.10.234.ge65dd.dirty\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"208371","messageId":"7vvcadgss0.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"CACBZZX552fnD+u9Zp-BhqDyYWN+OiyvCyub-xjMZ-_GXCG-vQA@mail.gmail.com","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-31T17:35:11Z","receivedAt":"2013-01-31T17:35:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:\n>> It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,\n>> push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it\n>> from documentation (even though it's still supported) to make the\n>> explanations more readable.\n>\n> I don't think this was a good move for the documentation. Now every\n> time I find an old repo with \"push.default=tracking\" I end up\n> wondering what it was a synonym for again, and other users who don't\n> know what it does will just assume it's an invalid value or something.\n>\n> We can't treat existing config values we still support as any other\n> deprecated feature. They still exist in files we have no control over,\n> and in people's brains who are reading \"man git-config\" trying to\n> remember what it meant.\n\nWow, that's a blast from the past.\n\nI tend to agree that deprecating and removing are quite different,\nbut a simple \"revert\" of the change would not be good, either.  We\nstill would want to _discourage_ its use.\n\nI think I can be persuaded to apply a patch that mentions 'tracking'\nas a side note.\n\nThanks.\n\n>\n>> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\n>> ---\n>> Feel free to squash into previous one if needed.\n>>\n>>  Documentation/config.txt |    1 -\n>>  1 file changed, 1 deletion(-)\n>>\n>> diff --git a/Documentation/config.txt b/Documentation/config.txt\n>> index e38fab1..ddf6043 100644\n>> --- a/Documentation/config.txt\n>> +++ b/Documentation/config.txt\n>> @@ -1693,7 +1693,6 @@ push.default::\n>>    makes `git push` and `git pull` symmetrical in the sense that `push`\n>>    will update the same remote ref as the one which is merged by\n>>    `git pull`.\n>> -* `tracking` - deprecated synonym for `upstream`.\n>>  * `current` - push the current branch to a branch of the same name.\n>>    +\n>>    The `current` and `upstream` modes are for those who want to\n>> --\n>> 1.7.10.234.ge65dd.dirty\n>>\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"208389","messageId":"20130131190747.GE27340@google.com","threadId":"30086","inReplyTo":"7vvcadgss0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-31T19:07:47Z","receivedAt":"2013-01-31T19:07:47Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJunio C Hamano wrote:\n\n> Wow, that's a blast from the past.\n>\n> I tend to agree that deprecating and removing are quite different,\n> but a simple \"revert\" of the change would not be good, either.  We\n> still would want to _discourage_ its use.\n\nHm, I was about to try adding a line in that vein, like\n\n * `tracking` - deprecated synonym for `upstream`.\n \nImagine my surprise when I saw that that is what you just said\nwould be no good:\n\n[...]\n>>>    `git pull`.\n>>> -* `tracking` - deprecated synonym for `upstream`.\n>>>  * `current` - push the current branch to a branch of the same name.\n\nI really do think that including `tracking` in the same list would be\nvaluable.  When I look over a friend's .gitconfig file to help track\ndown a problem she is running into, it is helpful if I can find the\nmeaning of each item in a straightforward way.\n\nIs the problem that \"deprecated\" is not precise enough?  For example,\nwould it make sense to say \"deprecated synonym for `upstream`.  Will\nbe dropped in git 2.1\" or something like that?\n\nMy two cents,\nJonathan\n"},{"id":"208391","messageId":"20130131191105.GF27340@google.com","threadId":"30086","inReplyTo":"20130131190747.GE27340@google.com","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-31T19:11:05Z","receivedAt":"2013-01-31T19:11:05Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> Is the problem that \"deprecated\" is not precise enough?  For example,\n> would it make sense to say \"deprecated synonym for `upstream`.  Will\n> be dropped in git 2.1\" or something like that?\n\nAlso, if we plan to remove support soon, we should start warning when\nthis setting is encountered so people know to update their\nconfiguration.\n\nJonathan\n"},{"id":"208395","messageId":"7vip6dgmx2.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20130131190747.GE27340@google.com","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-31T19:41:45Z","receivedAt":"2013-01-31T19:41:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>\n>> Wow, that's a blast from the past.\n>>\n>> I tend to agree that deprecating and removing are quite different,\n>> but a simple \"revert\" of the change would not be good, either.  We\n>> still would want to _discourage_ its use.\n>\n> Hm, I was about to try adding a line in that vein, like\n>\n>  * `tracking` - deprecated synonym for `upstream`.\n>  \n> Imagine my surprise when I saw that that is what you just said\n> would be no good:\n>\n> [...]\n>>>>    `git pull`.\n>>>> -* `tracking` - deprecated synonym for `upstream`.\n>>>>  * `current` - push the current branch to a branch of the same name.\n>\n> I really do think that including `tracking` in the same list would be\n> valuable.  When I look over a friend's .gitconfig file to help track\n> down a problem she is running into, it is helpful if I can find the\n> meaning of each item in a straightforward way.\n\nWhile I agree we would need a way for you to easily find `tracking`\nmentioned near that point, listing it as if it is a proper part of\nthe same list of possibilities is not the only way to do so.\n\nThe enumeration is used by two different audiences.  For those who\nwant to _learn_ what possibilities are available to them (i.e. they\nare not going from `tracking` to what it means, but going in the\nopposite direction), it should be unmistakingly clear that\n`tracking` is not a part of the choices they should make.  I do not\nthink the following list created by a simple \"revert\" makes it clear.\n\n    * `nothing` - do not push anything.\n    * `matching` - push all branches having the same name in both ends.\n    * `upstream` - push the current branch to ...\n    * `simple` - like `upstream`, but refuses to ...\n    * `tracking` - deprecated synonym for `upstream`.\n    * `current` - push the current branch to a branch of the same name.\n\nWhen scanning, most people will scan lines to see there are 6\nchoices without reading anything after '-' first, and then start\nreading the item that sounds plausible for them without necessarily\nreading the others.  That will imprint the word `tracking` in the\ncontext of choosing how to push, especially when that is not what\nthey end up using.\n\nThat is why I tend to prefer how check-ref-format documentation\ndescribes --print:\n\n        --normalize::\n                Normalize 'refname' by removing any leading slash (`/`)\n                characters and collapsing runs of adjacent slashes between\n                name components into a single slash.  Iff the normalized\n                refname is valid then print it to standard output and exit\n                with a status of 0.  (`--print` is a deprecated way to spell\n                `--normalize`.)\n\nWhen you are going from `tracking` to what it means, you have \\C-s\n(if you are viewing in Emacs) or '/' (if you are using less)\navailable.\n"},{"id":"208396","messageId":"20130131195712.GH27340@google.com","threadId":"30086","inReplyTo":"7vip6dgmx2.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-31T19:57:12Z","receivedAt":"2013-01-31T19:57:12Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> That is why I tend to prefer how check-ref-format documentation\n> describes --print:\n>\n>         --normalize::\n>                 Normalize 'refname' by removing any leading slash (`/`)\n>                 characters and collapsing runs of adjacent slashes between\n>                 name components into a single slash.  Iff the normalized\n>                 refname is valid then print it to standard output and exit\n>                 with a status of 0.  (`--print` is a deprecated way to spell\n>                 `--normalize`.)\n\nThat works because, as you mention, the usual way to look up an option\nin manpages is to search for \"--print\", including the two minus signs.\n\nUnfortunately an analagous approach in gitconfig(5) would be seriously\nbroken, because searching for \"tracking\" (no minus signs) is going to\nhit many false positives.  I do not think such a change would be an\nimprovement.\n\nMeanwhile I believe the prominent words \"deprecated synonym\" already\nmake it completely obvious that when I write a new config file, I should\nuse the modern option, unless I am trying to write a config file that\nalso works with older versions of git.  In the latter case (which\nunfortunately is not too uncommon), hiding the option is not going to\nmake my life easier.  What would allow me to make an informed choice\nis mentioning what version of git *introduced* the new name of the\noption:\n\n\t- `tracking` - deprecated old name for `upstream`, used by git\n\t  versions before 1.7.4.2.  Don't use this.\n\nAlso I do not think anyone claimed we are removing \"tracking\" from the\ndocumentation in order to stop people from using it.  The rationale\nwhen the patch was proposed is that it makes the documentation easier\nto read.  I agree with that rationale, with the caveat Avar mentioned.\nThere is a simple fix: just simplify the behavior being explained as\nwell, by biting the bullet and dropping the \"tracking\" synonym after a\nsuitable period in which it produces a warning.\n\nIn the meantime, the documentation is valuable, and pretending that\n\"tracking\" does not exist for everyone who does not confusedly reread\nthe docs a few times is just a way to lie to ourselves and make users'\nlives more difficult.  Is that really the intent?\n\nJonathan\n"},{"id":"208397","messageId":"7vehh1gm5i.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20130131191105.GF27340@google.com","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-31T19:58:17Z","receivedAt":"2013-01-31T19:58:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Jonathan Nieder wrote:\n>\n>> Is the problem that \"deprecated\" is not precise enough?  For example,\n>> would it make sense to say \"deprecated synonym for `upstream`.  Will\n>> be dropped in git 2.1\" or something like that?\n>\n> Also, if we plan to remove support soon, we should start warning when\n> this setting is encountered so people know to update their\n> configuration.\n\nI do not think this even needs to be removed.\n\nWe deprecate something for one of two reasons. One is when it was a\nbad idea to support it, and we would want to remove the support\neventually.  This needs a migration plan.\n\nThe other is when there are better ways available but we do not want\nto break the old way.  We still do not want to encourage the old way\nto new users.\n\nThe change from 'upstream' from 'tracking' is the latter.  The\nwording will confuse new users when they want to learn what\n'tracking' as a concept is, and it is better spelt 'upstream'.  But\nthe breakage is not serious enough to warrant forcing an old timer\nwho can explain these two concepts to newbies when needed to update\nhis configuration files he is not planning to show to newbies.\n"},{"id":"208398","messageId":"7va9rpgm06.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20130131195712.GH27340@google.com","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-31T20:01:29Z","receivedAt":"2013-01-31T20:01:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>\n>> That is why I tend to prefer how check-ref-format documentation\n>> describes --print:\n>>\n>>         --normalize::\n>>                 Normalize 'refname' by removing any leading slash (`/`)\n>>                 characters and collapsing runs of adjacent slashes between\n>>                 name components into a single slash.  Iff the normalized\n>>                 refname is valid then print it to standard output and exit\n>>                 with a status of 0.  (`--print` is a deprecated way to spell\n>>                 `--normalize`.)\n>\n> That works because, as you mention, the usual way to look up an option\n> in manpages is to search for \"--print\", including the two minus signs.\n>\n> Unfortunately an analagous approach in gitconfig(5) would be seriously\n> broken, because searching for \"tracking\" (no minus signs) is going to\n> hit many false positives.  I do not think such a change would be an\n> improvement.\n\nI thought your example was that you saw \"pull.default = tracking\"\nand wondering what it is.  Why do you need global search for\n\"tracking\", not just near pull.default is described, in the first\nplace?\n"},{"id":"208399","messageId":"20130131200434.GI27340@google.com","threadId":"30086","inReplyTo":"7vip6dgmx2.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-31T20:04:34Z","receivedAt":"2013-01-31T20:04:34Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n>                                                      For those who\n> want to _learn_ what possibilities are available to them (i.e. they\n> are not going from `tracking` to what it means, but going in the\n> opposite direction), it should be unmistakingly clear that\n> `tracking` is not a part of the choices they should make.\n\nUntil pre-1.7.4 versions of git fall out of use, I don't agree that\nthe above is true. :(\n\n\n>                                                            I do not\n> think the following list created by a simple \"revert\" makes it clear.\n>\n>     * `nothing` - do not push anything.\n>     * `matching` - push all branches having the same name in both ends.\n>     * `upstream` - push the current branch to ...\n>     * `simple` - like `upstream`, but refuses to ...\n>     * `tracking` - deprecated synonym for `upstream`.\n>     * `current` - push the current branch to a branch of the same name.\n\nHow about the following?\n\n    * `nothing` - ...\n    * `matching` - ...\n    * `upstream` - ...\n    * `simple` - ...\n    * `current` - ...\n\n  For compatibility with ancient config files, the following synonym\n  is also supported.  Don't use it.\n\n    * `tracking` - old name for `upstream`\n"},{"id":"208400","messageId":"vpqwqutw1xw.fsf@grenoble-inp.fr","threadId":"30086","inReplyTo":"20130131200434.GI27340@google.com","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-01-31T20:08:11Z","receivedAt":"2013-01-31T20:08:11Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> How about the following?\n>\n>     * `nothing` - ...\n>     * `matching` - ...\n>     * `upstream` - ...\n>     * `simple` - ...\n>     * `current` - ...\n>\n>   For compatibility with ancient config files, the following synonym\n>   is also supported.  Don't use it.\n>\n>     * `tracking` - old name for `upstream`\n\nSounds good to me.\n\nI'm the author of the removal patch, but the patch was just part of a\nlarger serie explaining push.default, the idea of cleaning up the\nobsolete alias came in the discussion and I did it, but I'm fine with\nreintroducing it in the doc (as long as it does not disturb new users\ntoo much).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"208401","messageId":"20130131201144.GJ27340@google.com","threadId":"30086","inReplyTo":"7va9rpgm06.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-31T20:11:44Z","receivedAt":"2013-01-31T20:11:44Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>> That works because, as you mention, the usual way to look up an option\n>> in manpages is to search for \"--print\", including the two minus signs.\n>>\n>> Unfortunately an analagous approach in gitconfig(5) would be seriously\n>> broken, because searching for \"tracking\" (no minus signs) is going to\n>> hit many false positives.  I do not think such a change would be an\n>> improvement.\n>\n> I thought your example was that you saw \"pull.default = tracking\"\n> and wondering what it is.  Why do you need global search for\n> \"tracking\", not just near pull.default is described, in the first\n> place?\n\nBecause the UI for local searches in web browsers and man pagers is\nseriously lacking.  Or, because people have bad habits and do not\ntake apppropriate advantage of search in small subsections of a\ndocument.  All I know is that I have seen myself and others doing\nsearches analagous to \"--print\" and not seen searches analagous to\n\"tracking\".\n\nAm I really the only one that doesn't see the \"--print\" change as\nhiding an option and sees burying \"tracking\" in the text as\nqualitatively different?\n\nJonathan\n"},{"id":"208404","messageId":"7v622dgl2o.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20130131200434.GI27340@google.com","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-31T20:21:35Z","receivedAt":"2013-01-31T20:21:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>\n>>                                                      For those who\n>> want to _learn_ what possibilities are available to them (i.e. they\n>> are not going from `tracking` to what it means, but going in the\n>> opposite direction), it should be unmistakingly clear that\n>> `tracking` is not a part of the choices they should make.\n>\n> Until pre-1.7.4 versions of git fall out of use, I don't agree that\n> the above is true. :(\n\nThe documentation ships with the version that the above is true.  We\nare not making an update to documentation that comes with ancient\nversions.\n\n\n>>                                                            I do not\n>> think the following list created by a simple \"revert\" makes it clear.\n>>\n>>     * `nothing` - do not push anything.\n>>     * `matching` - push all branches having the same name in both ends.\n>>     * `upstream` - push the current branch to ...\n>>     * `simple` - like `upstream`, but refuses to ...\n>>     * `tracking` - deprecated synonym for `upstream`.\n>>     * `current` - push the current branch to a branch of the same name.\n>\n> How about the following?\n>\n>     * `nothing` - ...\n>     * `matching` - ...\n>     * `upstream` - ...\n>     * `simple` - ...\n>     * `current` - ...\n>\n>   For compatibility with ancient config files, the following synonym\n>   is also supported.  Don't use it.\n>\n>     * `tracking` - old name for `upstream`\n\nDidn't I say I am fine to mention it \"as a side note\" in the\noriginal message you started responding to?\n"},{"id":"208406","messageId":"C3D8C713BDBF41CDA0BC3469316FF119@PhilipOakley","threadId":"30086","inReplyTo":"20130131200434.GI27340@google.com","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-01-31T20:36:16Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jonathan Nieder\" <jrnieder@gmail.com>\nSent: Thursday, January 31, 2013 8:04 PM\n> Junio C Hamano wrote:\n>\n>>                                                      For those who\n>> want to _learn_ what possibilities are available to them (i.e. they\n>> are not going from `tracking` to what it means, but going in the\n>> opposite direction), it should be unmistakingly clear that\n>> `tracking` is not a part of the choices they should make.\n>\n> Until pre-1.7.4 versions of git fall out of use, I don't agree that\n> the above is true. :(\n>\n>\n>>                                                            I do not\n>> think the following list created by a simple \"revert\" makes it clear.\n>>\n>>     * `nothing` - do not push anything.\n>>     * `matching` - push all branches having the same name in both \n>> ends.\n>>     * `upstream` - push the current branch to ...\n>>     * `simple` - like `upstream`, but refuses to ...\n>>     * `tracking` - deprecated synonym for `upstream`.\n\n>From a simple user perspective, I'd simply place it, in brackets and at \nthe end of the list.\n\ne.g.     [* `tracking` - deprecated synonym for `upstream`.]\n\nThe leading bracket makes it obvious that it's different, and that the \ndescription needs to be read, rather than folk simply re-using a half \nremembered option, gleaned from an old blog.\n\nHowever formatting the leading bracket may not be as easy as the plain \ntext version.\n\n>>     * `current` - push the current branch to a branch of the same \n>> name.\n>\n> How about the following?\n>\n>    * `nothing` - ...\n>    * `matching` - ...\n>    * `upstream` - ...\n>    * `simple` - ...\n>    * `current` - ...\n>\n>  For compatibility with ancient config files, the following synonym\n>  is also supported.  Don't use it.\n>\n>    * `tracking` - old name for `upstream`\n\n? s/old/deprecated/  or  s/old/outdated/  for those who don't understand \nthe jargon. \n"},{"id":"208407","messageId":"7vwqutf5jv.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20130131201144.GJ27340@google.com","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-31T20:42:12Z","receivedAt":"2013-01-31T20:42:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Am I really the only one that doesn't see the \"--print\" change as\n> hiding an option and sees burying \"tracking\" in the text as\n> qualitatively different?\n\nSorry, but I do not understand the question.\n\nWe are hiding/burying the \"--print\" option to make it clear that it\nis not a member with the same footing as others belonging to the\ngroup of options to the command.  It is accepted, but there is no\nreason for the user to choose it over --normalize.\n\nWe want to make sure that \"tracking\" does not appear as if it is a\nmember of the pull.default set with equal rights as others.  It is\naccepted, but there is no reason for the user to choose it over\n\"upstream\".\n"},{"id":"208408","messageId":"7vsj5hf5fh.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"7vwqutf5jv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-31T20:44:50Z","receivedAt":"2013-01-31T20:44:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n>\n>> Am I really the only one that doesn't see the \"--print\" change as\n>> hiding an option and sees burying \"tracking\" in the text as\n>> qualitatively different?\n>\n> Sorry, but I do not understand the question.\n>\n> We are hiding/burying the \"--print\" option to make it clear that it\n> is not a member with the same footing as others belonging to the\n> group of options to the command.  It is accepted, but there is no\n> reason for the user to choose it over --normalize.\n>\n> We want to make sure that \"tracking\" does not appear as if it is a\n> member of the pull.default set with equal rights as others.  It is\n> accepted, but there is no reason for the user to choose it over\n> \"upstream\".\n\nNow I re-read the proposed update, I think it is an improvement over\na straight revert in that it makes it clear that 'tracking' does not\nbelong, but I still think it is better to make it a sidenote to the\n'upstream'.  It makes the connection between the two stronger.\n"},{"id":"208409","messageId":"7vobg5f55t.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"7v622dgl2o.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-31T20:50:38Z","receivedAt":"2013-01-31T20:50:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"How about doing it this way?  I do not think anything that is\ndeprecated even deserves a separate section and \"do not use it!\"\nheading.\n\n-- >8 --\nWhen looking at a configuration file edited long time ago, a user\nmay find 'pull.default = tracking' and wonder what it means.\nInstead of not mentioning it, add it to the description in a way\nthat makes it clear that users have no reason to add new uses of it\npreferring over 'upstream'.\n\n Documentation/config.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex d7ec507..8441050 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1795,7 +1795,8 @@ push.default::\n   +\n   This is currently the default, but Git 2.0 will change the default\n   to `simple`.\n-* `upstream` - push the current branch to its upstream branch.\n+* `upstream` - push the current branch to its upstream branch\n+  (`tracking` is a deprecated synonym for this).\n   With this, `git push` will update the same remote ref as the one which\n   is merged by `git pull`, making `push` and `pull` symmetrical.\n   See \"branch.<name>.merge\" for how to configure the upstream branch.\n"},{"id":"208410","messageId":"20130131210002.GK27340@google.com","threadId":"30086","inReplyTo":"7vobg5f55t.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-31T21:00:02Z","receivedAt":"2013-01-31T21:00:02Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> How about doing it this way?\n[...]\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1795,7 +1795,8 @@ push.default::\n>    +\n>    This is currently the default, but Git 2.0 will change the default\n>    to `simple`.\n> -* `upstream` - push the current branch to its upstream branch.\n> +* `upstream` - push the current branch to its upstream branch\n> +  (`tracking` is a deprecated synonym for this).\n\nI have already explained that I believe this is a bad idea and why and\nproposed an alternative.  I take it that either we are\nmiscommunicating or we fundamentally disagree about the role of\ndocumentation. :(\n"},{"id":"208411","messageId":"20130131210804.GL27340@google.com","threadId":"30086","inReplyTo":"7v622dgl2o.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-31T21:08:04Z","receivedAt":"2013-01-31T21:08:04Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n>> Junio C Hamano wrote:\n\n>>>                                                      For those who\n>>> want to _learn_ what possibilities are available to them (i.e. they\n>>> are not going from `tracking` to what it means, but going in the\n>>> opposite direction), it should be unmistakingly clear that\n>>> `tracking` is not a part of the choices they should make.\n>>\n>> Until pre-1.7.4 versions of git fall out of use, I don't agree that\n>> the above is true. :(\n>\n> The documentation ships with the version that the above is true.  We\n> are not making an update to documentation that comes with ancient\n> versions.\n\nPart of the context that I should have mentioned but didn't is that it\nis common to put $HOME on a shared filesystem.\n\n[...]\n>> How about the following?\n>>\n>>     * `nothing` - ...\n>>     * `matching` - ...\n>>     * `upstream` - ...\n>>     * `simple` - ...\n>>     * `current` - ...\n>>\n>>   For compatibility with ancient config files, the following synonym\n>>   is also supported.  Don't use it.\n>>\n>>     * `tracking` - old name for `upstream`\n>\n> Didn't I say I am fine to mention it \"as a side note\" in the\n> original message you started responding to?\n\nYes, I understood what you were proposing and I directly disagreed\nwith it and explained why.\n\nThe above is something like a compromise --- more precisely, it is an\nattempt to do something better than a straight revert and to\nunderstand whether it would address your objection.  Clearly it\ndoesn't.  I don't understand why.\n\nPerhaps the \"Don't use it\" is over the top and that is your complaint?\nIt's true that if I were writing it without your objection in mind, I\nwouldn't have included that sentence.  It was written on the\nassumption that you want to discourage people from using the\n\"tracking\" synonym --- I am not personally convinced that that is\nworth discouraging at all, but it's fine with me if the consensus is\nto do so.\n\nJonathan\n"},{"id":"208434","messageId":"7vr4l0dece.fsf@alter.siamese.dyndns.org","threadId":"30086","inReplyTo":"20130131210002.GK27340@google.com","subject":"Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-01T01:15:13Z","receivedAt":"2013-02-01T01:15:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> [...]\n>> --- a/Documentation/config.txt\n>> +++ b/Documentation/config.txt\n>> @@ -1795,7 +1795,8 @@ push.default::\n>>    +\n>>    This is currently the default, but Git 2.0 will change the default\n>>    to `simple`.\n>> -* `upstream` - push the current branch to its upstream branch.\n>> +* `upstream` - push the current branch to its upstream branch\n>> +  (`tracking` is a deprecated synonym for this).\n>\n> I have already explained that I believe this is a bad idea and why and\n> proposed an alternative.  I take it that either we are\n> miscommunicating or we fundamentally disagree about the role of\n> documentation. :(\n\nWhatever.\n\nFor tonight, I'll queue this version on 'pu' primarily because I do\nnot want to think about it anymore today and because I do not want\nto see us forget that we have to fix this in some way, and this was\nthe only one that I can simply \"git am\" on this topic. It is not\nbecause I want to say \"this is the version we are going to use,\nstfu!\"  This topic does not even deserve such inter-developer\ntension, IMHO.\n\n    doc: mention tracking for pull.default\n    \n    When looking at a configuration file edited long time ago, a user\n    may find 'pull.default = tracking' and wonder what it means, but\n    earlier we stopped mentioning this value, even though the code still\n    support it and more importantly, we have no intention to force old\n    timers to update their configuration files.\n    \n    Instead of not mentioning it, add it to the description in a way\n    that makes it clear that users have no reason to add new uses of it\n    preferring over 'upstream', by not listing it as a separate item on\n    the same footing as other values but as a deprecated synonym of the\n    'upstream' in its description.\n    \n    Signed-off-by: Junio C Hamano <gitster@pobox.com>\n"}]}