{"thread":{"id":"12183","subject":"git push [rejected] question","startedAt":"2008-02-18T22:15:01Z","lastAt":"2008-02-20T03:15:18Z","messageCount":19,"participants":["Jason Garber","Jeff King","Jay Soffian","Johannes Schindelin","Govind Salinas","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"69216","messageId":"E7DE807861E8474E8AC3DC7AC2C75EE50542F2F1@34093-EVS2C1.exchange.rackspace.com","threadId":"12183","inReplyTo":null,"subject":"git push [rejected] question","fromName":"Jason Garber","fromEmail":"jgarber@ionzoft.com","sentAt":"2008-02-18T22:15:01Z","receivedAt":"2008-02-18T22:15:01Z","isPatch":false,"sender":{"key":"jgarber@ionzoft.com","avatar":"https://gravatar.com/avatar/e8e5cac5f615739d425dd7232dc76313337cd76ad7b9f078694f74725409eae8?d=mp&s=160"},"body":"Hello,\n\nOne of our users had this come up today.  He (on a different branch) did a push (successfully) earlier today.  Upon pushing some more changes this afternoon in the \"Task/4919...\" branch, the following message was received:\n\n--\n[caleb@neon VOS4]$ git push\nEnter passphrase for key '/home/caleb/.ssh/id_rsa':\nTo ssh://git@code.izrm.com/~/WhiteBoot4/VOS4-NEW\n ! [rejected]        Issue/Default -> Issue/Default (non-fast forward)\n ! [rejected]        Issue/Task_4831_MUP_Survey_Layout -> Issue/Task_4831_MUP_Survey_Layout (non-fast forward)\n ! [rejected]        Task/4872-MUP-APlan-promotion -> Task/4872-MUP-APlan-promotion (non-fast forward)\n <snip>\nerror: failed to push to 'ssh://git@code.izrm.com/~/WhiteBoot4/VOS4-NEW'\n--\n\n\nHowever the branch in question was pushed successfully (despite the error message).\n\n* Task/4919-MUP-Agent-ID-promotion         7e80ca6\n  origin/Task/4919-MUP-Agent-ID-promotion  7e80ca6\n\nAs far as I can tell, most (if not all) of the branches that were rejected were not changed today.\n\n\nAny ideas or pointers for where I should look to resolve this?\n\n** git version 1.5.4.1 **\n\n--\nBest Regards,\n \nJason Garber\nSenior Systems Engineer\nIonZoft, Inc.\n \n(814) 941-2390\njgarber@ionzoft.com\n \n \n"},{"id":"69231","messageId":"20080219043353.GA23239@sigill.intra.peff.net","threadId":"12183","inReplyTo":"E7DE807861E8474E8AC3DC7AC2C75EE50542F2F1@34093-EVS2C1.exchange.rackspace.com","subject":"Re: git push [rejected] question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-19T04:33:53Z","receivedAt":"2008-02-19T04:33:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 18, 2008 at 04:15:01PM -0600, Jason Garber wrote:\n\n> One of our users had this come up today.  He (on a different branch)\n> did a push (successfully) earlier today.  Upon pushing some more\n> changes this afternoon in the \"Task/4919...\" branch, the following\n> message was received:\n\nI think the user is missing one fundamental aspect of pushing: the\nbehavior of \"git push\" without any refspecs specified is to push all\nmatching refs (i.e., if you have branch refs/heads/Issue/Default and so\ndoes the remote, then it will attempt to push). So no matter what branch\nhe is on when doing the push, it tries to push many such branches.\n\nIf you want to push just the current branch, try:\n\n  git push origin HEAD\n\n> [caleb@neon VOS4]$ git push\n> Enter passphrase for key '/home/caleb/.ssh/id_rsa':\n> To ssh://git@code.izrm.com/~/WhiteBoot4/VOS4-NEW\n>  ! [rejected]        Issue/Default -> Issue/Default (non-fast forward)\n>  ! [rejected]        Issue/Task_4831_MUP_Survey_Layout -> Issue/Task_4831_MUP_Survey_Layout (non-fast forward)\n>  ! [rejected]        Task/4872-MUP-APlan-promotion -> Task/4872-MUP-APlan-promotion (non-fast forward)\n>  <snip>\n> error: failed to push to 'ssh://git@code.izrm.com/~/WhiteBoot4/VOS4-NEW'\n\nThese branches are rejected because he has local branches of the same\nname that are _behind_ where the remote is. In other words, pushing\nwould roll back history, and therefore these pushes are rejected without\nthe '-f' option to force.\n\nThese branches get in this state through something like:\n\n  # check out a local branch to match an upstream branch\n  git checkout -b Issue/Default origin/Issue/Default\n  # now hack on it or whatever\n  hack hack hack\n  build build build\n  # and we're finished, so let's go back to another branch\n  git checkout Task/4919...\n  # time passes, and somebody else pushes changes to Issue/Default\n\nAnd now at this point the user's Issue/Default is behind the remote's.\nPushing would roll back history, and so is rejected.\n\n> However the branch in question was pushed successfully (despite the error message).\n> \n> * Task/4919-MUP-Agent-ID-promotion         7e80ca6\n>   origin/Task/4919-MUP-Agent-ID-promotion  7e80ca6\n\nYes, presumably that was in your <snip> section above. The \"error:\"\nmessage is reported if pushing _any_ branch fails or is rejected. If you\nare interested in pushing only the one branch, then you need to say so\nexplicitly.\n\n-Peff\n"},{"id":"69256","messageId":"76718490802190509k20225092o66853916f48e08b1@mail.gmail.com","threadId":"12183","inReplyTo":"20080219043353.GA23239@sigill.intra.peff.net","subject":"Re: git push [rejected] question","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-02-19T13:09:36Z","receivedAt":"2008-02-19T13:09:36Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Feb 18, 2008 11:33 PM, Jeff King <peff@peff.net> wrote:\n> I think the user is missing one fundamental aspect of pushing: the\n> behavior of \"git push\" without any refspecs specified is to push all\n> matching refs (i.e., if you have branch refs/heads/Issue/Default and so\n> does the remote, then it will attempt to push). So no matter what branch\n> he is on when doing the push, it tries to push many such branches.\n>\n> If you want to push just the current branch, try:\n>\n>   git push origin HEAD\n\ngit-push(1) is a bit confusing I think:\n\n  \"Note: If no explicit refspec is found, (that is neither on the command line\n  nor in any Push line of the corresponding remotes file---see below), then all\n  the heads that exist both on the local side and on the remote side are\n  updated.\"\n\nis clear enough, but then:\n\n  \"--all Instead of naming each ref to push, specifies that all refs under\n  $GIT_DIR/refs/heads/ be pushed.\"\n\nSo what is '--all' needed for then?\n\nIt seems like the default should be to push just the current branch\n... this would correspond to what a user of git pull expects (even\nthough the converse of git-push is really git-fetch, for a new user,\nthat might not be entirely clear).\n\nj.\n"},{"id":"69270","messageId":"20080219150826.GA24499@sigill.intra.peff.net","threadId":"12183","inReplyTo":"76718490802190509k20225092o66853916f48e08b1@mail.gmail.com","subject":"Re: git push [rejected] question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-19T15:08:27Z","receivedAt":"2008-02-19T15:08:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 19, 2008 at 08:09:36AM -0500, Jay Soffian wrote:\n\n> git-push(1) is a bit confusing I think:\n> \n>   \"Note: If no explicit refspec is found, (that is neither on the command line\n>   nor in any Push line of the corresponding remotes file---see below), then all\n>   the heads that exist both on the local side and on the remote side are\n>   updated.\"\n> \n> is clear enough, but then:\n> \n>   \"--all Instead of naming each ref to push, specifies that all refs under\n>   $GIT_DIR/refs/heads/ be pushed.\"\n> \n> So what is '--all' needed for then?\n\nIn the first case we push \"matching\" refs: any head which already exists\non both sides. In the second case, we push all heads which exist on the\nsending send, whether or not a matching ref already exists on the remote\nside.\n\nI think the first statement could be made to emphasize the matching\naspect a little more, since a quick read makes it seem like it's pushing\nthe union of the two sets, not the intersection of the two sets.\n\n> It seems like the default should be to push just the current branch\n> ... this would correspond to what a user of git pull expects (even\n> though the converse of git-push is really git-fetch, for a new user,\n> that might not be entirely clear).\n\nI agree with you, but others do not; this has come up several times in\nthe past (there was some discussion a week or two ago in the thread\n\"Minor annoyance with git push\").\n\n-Peff\n"},{"id":"69272","messageId":"76718490802190718t5e70abb2x8f96fc7154576594@mail.gmail.com","threadId":"12183","inReplyTo":"20080219150826.GA24499@sigill.intra.peff.net","subject":"Re: git push [rejected] question","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-02-19T15:18:09Z","receivedAt":"2008-02-19T15:18:09Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Feb 19, 2008 10:08 AM, Jeff King <peff@peff.net> wrote:\n>\n> In the first case we push \"matching\" refs: any head which already exists\n> on both sides. In the second case, we push all heads which exist on the\n> sending send, whether or not a matching ref already exists on the remote\n> side.\n\nI'd like to nominate you to rewrite all of the git documentation from\nscratch. :-) Your explanations are extremely clear.\n\n> > It seems like the default should be to push just the current branch\n> > ... this would correspond to what a user of git pull expects (even\n> > though the converse of git-push is really git-fetch, for a new user,\n> > that might not be entirely clear).\n>\n> I agree with you, but others do not\n\nSounds like an opportunity for a config option.\n\nj.\n"},{"id":"69273","messageId":"20080219152154.GB24499@sigill.intra.peff.net","threadId":"12183","inReplyTo":"E7DE807861E8474E8AC3DC7AC2C75EE50542F62D@34093-EVS2C1.exchange.rackspace.com","subject":"Re: git push [rejected] question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-19T15:21:54Z","receivedAt":"2008-02-19T15:21:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 19, 2008 at 08:45:32AM -0600, Jason Garber wrote:\n\n> ### Push from Issue/1 with non-fast-forward Issue/3 k###\n> \n>   [jason@neon wc1]$ git push\n>   Counting objects: 5, done.\n>   Writing objects: 100% (3/3), 242 bytes, done.\n>   Total 3 (delta 0), reused 0 (delta 0)\n>   Unpacking objects: 100% (3/3), done.\n>   To /var/var-home/jason/Code/test/git/repo/.git\n>      142e136..c85b3dc  Issue/1 -> Issue/1\n>    ! [rejected]        Issue/3 -> Issue/3 (non-fast forward)\n>   error: failed to push to '/var/var-home/jason/Code/test/git/repo/.git'\n> \n> \n> The issue with the above error message is that it indicates to the\n> user that the push failed - even though the push was partially\n> successful.\n\nYes, the final line is somewhat ambiguous if read by itself. The\ntransport mechanism is abstracted, and we don't pass back to \"git push\"\nthe number of successful and error refs, so we know only that there was\nan error.\n\nHowever, the idea is that the detailed status information on each ref\nhas _already_ been output, and the user should look at that. And indeed,\nin your example, we can see that Issue/1 was pushed successfully, while\nIssue/3 was not.\n\nSo I think it is a matter of:\n\n  1. The table's terseness did not make clear to you that Issue/1 was\n     not only attempted for push, but was successfully pushed. This\n     should probably be dealt with by a documentation update to\n     git-push.\n\n  2. The error message implies that the push failed, and a user might\n     expect an all-or-nothing behavior. It might be enough to change\n     this to just \"error: failed to push some refs to ...\" without\n     actually counting the refs (as you suggested).\n\n>   [jason@neon wc1]$ git push\n>   To /var/var-home/jason/Code/test/git/repo/.git\n>      c85b3dc..c85b3dc  Issue/1 -> Issue/1 (Everything up-to-date)\n>    ! [rejected]        Issue/3 -> Issue/3 (non-fast forward)\n>   error: some errors encountered during push to '/var/var-home/jason/Code/test/git/repo/.git'.  See above for detail.\n> \n> (it would be nice to see the status of each attempted branch if --all\n> was specified or implied as the default behavior)\n\nTry \"git push -v\". We explicitly don't show up to date branches by\ndefault because they tend to clutter the output.\n\n-Peff\n"},{"id":"69274","messageId":"20080219152549.GC24499@sigill.intra.peff.net","threadId":"12183","inReplyTo":"76718490802190718t5e70abb2x8f96fc7154576594@mail.gmail.com","subject":"Re: git push [rejected] question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-19T15:25:49Z","receivedAt":"2008-02-19T15:25:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 19, 2008 at 10:18:09AM -0500, Jay Soffian wrote:\n\n> I'd like to nominate you to rewrite all of the git documentation from\n> scratch. :-) Your explanations are extremely clear.\n\nDoh! This is why nobody writes clear explanations: it gets you nominated\nfor more work. ;)\n\n> > > It seems like the default should be to push just the current branch\n> > > ... this would correspond to what a user of git pull expects (even\n> > > though the converse of git-push is really git-fetch, for a new user,\n> > > that might not be entirely clear).\n> >\n> > I agree with you, but others do not\n> \n> Sounds like an opportunity for a config option.\n\nAgain I agree, though I think there is some resistance to that (see the\nthread I mentioned). Junio's opinion seems to be \"why can't they just\nuse 'git push <remote> HEAD'?\" (and he suggested a 'git push HEAD'\nshorthand syntax, as well).\n\nBut then, nobody has put forth a patch, so I think if you wanted to\nargue it, the best way would be to do so (though I think it would be\nrejected, it would give those who wanted to try it something to play\nwith).\n\n-Peff\n"},{"id":"69276","messageId":"alpine.LSU.1.00.0802191559320.30505@racer.site","threadId":"12183","inReplyTo":"20080219152549.GC24499@sigill.intra.peff.net","subject":"Re: git push [rejected] question","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-19T15:59:51Z","receivedAt":"2008-02-19T15:59:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 Feb 2008, Jeff King wrote:\n\n> On Tue, Feb 19, 2008 at 10:18:09AM -0500, Jay Soffian wrote:\n> \n> > I'd like to nominate you to rewrite all of the git documentation from \n> > scratch. :-) Your explanations are extremely clear.\n> \n> Doh! This is why nobody writes clear explanations: it gets you nominated \n> for more work. ;)\n\nNo good deed goes unpunished, they used to say.\n\nCiao,\nDscho\n"},{"id":"69278","messageId":"alpine.LSU.1.00.0802191610480.30505@racer.site","threadId":"12183","inReplyTo":"20080219152549.GC24499@sigill.intra.peff.net","subject":"[PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-19T16:14:35Z","receivedAt":"2008-02-19T16:14:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n---\n\n\tOn Tue, 19 Feb 2008, Jeff King wrote:\n\n\t> On Tue, Feb 19, 2008 at 10:18:09AM -0500, Jay Soffian wrote:\n\t> > > > It seems like the default should be to push just the \n\t> > > > current branch ... this would correspond to what a user of \n\t> > > > git pull expects (even though the converse of git-push is \n\t> > > > really git-fetch, for a new user, that might not be \n\t> > > > entirely clear).\n\t> > >\n\t> > > I agree with you, but others do not\n\t> > \n\t> > Sounds like an opportunity for a config option.\n\t> \n\t> Again I agree, though I think there is some resistance to that \n\t> (see the thread I mentioned). Junio's opinion seems to be \"why \n\t> can't they just use 'git push <remote> HEAD'?\" (and he suggested \n\t> a 'git push HEAD' shorthand syntax, as well).\n\n\tFWIW I would resist, just because that config option would change \n\tthe _semantics_ of a git program.\n\n\tJust think about the IRC channel.  \"How do I update only HEAD?\" --\n\t\"Just say 'git push'\" -- \"No, that updates nothing\" -- \"Well, \n\tworks here\" -- \"But not here!\" ... \"Can _nobody_ help me?\"\n\n\tHaving inconsistent semantics is wrong, wrong, wrong.\n\n\t> But then, nobody has put forth a patch, so I think if you wanted\n\t> to argue it, the best way would be to do so (though I think it \n\t> would be rejected, it would give those who wanted to try it \n\t> something to play with).\n\n\tThis is a tongue-in-cheek patch.  Just so that nobody can say that\n\tthere were no patches.\n\n builtin-push.c |    8 ++++++++\n 1 files changed, 8 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-push.c b/builtin-push.c\nindex c8cb63e..7bcb141 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -134,6 +134,14 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tflags |= TRANSPORT_PUSH_ALL;\n \tif (mirror)\n \t\tflags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);\n+\tif (!all && argc < 2)\n+\t\twarning(\"Pushing without branch names is deprecated.\\n\"\n+\t\t\t\"Too many users just assumed what it should do\\n\"\n+\t\t\t\"according to them, got burned, and blamed us,\\n\"\n+\t\t\t\"the good git developers.\\n\\n\"\n+\t\t\t\"So everybody has to suffer now, and get used to\\n\"\n+\t\t\t\"new semantics.\\n\\n\"\n+\t\t\t\"Thank you for your time.\\n\");\n \n \tif (argc > 0) {\n \t\trepo = argv[0];\n"},{"id":"69286","messageId":"E7DE807861E8474E8AC3DC7AC2C75EE50542F7F6@34093-EVS2C1.exchange.rackspace.com","threadId":"12183","inReplyTo":"alpine.LSU.1.00.0802191610480.30505@racer.site","subject":"RE: [PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Jason Garber","fromEmail":"jgarber@ionzoft.com","sentAt":"2008-02-19T16:21:33Z","receivedAt":"2008-02-19T16:21:33Z","isPatch":true,"sender":{"key":"jgarber@ionzoft.com","avatar":"https://gravatar.com/avatar/e8e5cac5f615739d425dd7232dc76313337cd76ad7b9f078694f74725409eae8?d=mp&s=160"},"body":"+\tif (!all && argc < 2)\n+\t\twarning(\"Pushing without branch names is deprecated.\\n\"\n+\t\t\t\"Too many users just assumed what it should\ndo\\n\"\n+\t\t\t\"according to them, got burned, and blamed\nus,\\n\"\n+\t\t\t\"the good git developers.\\n\\n\"\n+\t\t\t\"So everybody has to suffer now, and get used\nto\\n\"\n+\t\t\t\"new semantics.\\n\\n\"\n+\t\t\t\"Thank you for your time.\\n\");\n\n\nQuite accurate... lol.\n"},{"id":"69288","messageId":"20080219163743.GA31668@sigill.intra.peff.net","threadId":"12183","inReplyTo":"alpine.LSU.1.00.0802191610480.30505@racer.site","subject":"Re: [PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-19T16:37:44Z","receivedAt":"2008-02-19T16:37:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 19, 2008 at 04:14:35PM +0000, Johannes Schindelin wrote:\n\n> Subject: [PATCH(TIC)] push: annoy all users by deprecating the default\n\nHeh. It is a good sign that git has made the patch-generation workflow\nso pleasant to use that we are willing to make patches for the sake of\nhumor. :)\n\n> \tFWIW I would resist, just because that config option would change \n> \tthe _semantics_ of a git program.\n> \n> \tJust think about the IRC channel.  \"How do I update only HEAD?\" --\n> \t\"Just say 'git push'\" -- \"No, that updates nothing\" -- \"Well, \n> \tworks here\" -- \"But not here!\" ... \"Can _nobody_ help me?\"\n\nJust say \"git push origin HEAD\"?\n\n> diff --git a/builtin-push.c b/builtin-push.c\n> index c8cb63e..7bcb141 100644\n> --- a/builtin-push.c\n> +++ b/builtin-push.c\n> @@ -134,6 +134,14 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n>  \t\tflags |= TRANSPORT_PUSH_ALL;\n>  \tif (mirror)\n>  \t\tflags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);\n> +\tif (!all && argc < 2)\n> +\t\twarning(\"Pushing without branch names is deprecated.\\n\"\n> +\t\t\t\"Too many users just assumed what it should do\\n\"\n> +\t\t\t\"according to them, got burned, and blamed us,\\n\"\n> +\t\t\t\"the good git developers.\\n\\n\"\n> +\t\t\t\"So everybody has to suffer now, and get used to\\n\"\n> +\t\t\t\"new semantics.\\n\\n\"\n> +\t\t\t\"Thank you for your time.\\n\");\n>  \n>  \tif (argc > 0) {\n>  \t\trepo = argv[0];\n\nYou forgot to add a \"--matching\" option in case people want to\nexplicitly request the old behavior. ;P\n\nSeriously, though, I think it is not just new users. It is that for some\n(many? most?) people, wanting to push just the HEAD is the _normal_\nworkflow. So they must remember to always say \"git push origin HEAD\",\nand if they ever forget, the side effects are non-trivial to clean up.\n\n-Peff\n"},{"id":"69289","messageId":"alpine.LSU.1.00.0802191638520.30505@racer.site","threadId":"12183","inReplyTo":"E7DE807861E8474E8AC3DC7AC2C75EE50542F7F6@34093-EVS2C1.exchange.rackspace.com","subject":"RE: [PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-19T16:41:28Z","receivedAt":"2008-02-19T16:41:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 Feb 2008, Jason Garber wrote:\n\n> +\tif (!all && argc < 2)\n> +\t\twarning(\"Pushing without branch names is deprecated.\\n\"\n> +\t\t\t\"Too many users just assumed what it should\n> do\\n\"\n> +\t\t\t\"according to them, got burned, and blamed\n> us,\\n\"\n> +\t\t\t\"the good git developers.\\n\\n\"\n> +\t\t\t\"So everybody has to suffer now, and get used\n> to\\n\"\n> +\t\t\t\"new semantics.\\n\\n\"\n> +\t\t\t\"Thank you for your time.\\n\");\n> \n> \n> Quite accurate... lol.\n\nHeh.  FWIW I think I might just go on with that patch, until those who \n_should_ care deeply enough about it shut me up with code...\n\nNote that even if I vent here a bit, there's a good side to it: my patch \nshould be a good start (actually, I think it is more than just a start, \nbut hey, it's not like I want my patch to _really_ go into mainline).\n\nThis is my current state:\n\n Documentation/git-push.txt |   16 +++++++++++++---\n builtin-push.c             |   18 ++++++++++++++++++\n 2 files changed, 31 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 5f24944..d373d05 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -9,8 +9,10 @@ git-push - Update remote refs along with associated objects\n SYNOPSIS\n --------\n [verse]\n-'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]\n-           [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]\n+'git-push' [--all] [-m | --matching] [--dry-run] [--tags]\n+\t   [--receive-pack=<git-receive-pack>]\n+\t   [--repo=all] [-f | --force] [-v | --verbose]\n+\t   [<repository> <refspec>...]\n \n DESCRIPTION\n -----------\n@@ -49,7 +51,8 @@ Note: If no explicit refspec is found, (that is neither\n on the command line nor in any Push line of the\n corresponding remotes file---see below), then all the\n heads that exist both on the local side and on the remote\n-side are updated.\n+side are updated.  This behavior is DEPRECATED and will go\n+away in the future.  Use the `--matching` option in the future.\n +\n `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.\n +\n@@ -63,6 +66,13 @@ the remote repository.\n \tInstead of naming each ref to push, specifies that all\n \trefs under `$GIT_DIR/refs/heads/` be pushed.\n \n+-m, \\--matching::\n+\tPush all refs that are present both locally and remotely.\n+\tThis used to be the default action if no ref was specified,\n+\tuntil a few users who cannot read man pages prevailed in\n+\ttheir assumption that the default action should not be what\n+\tit was documented to be.\n+\n \\--mirror::\n \tInstead of naming each ref to push, specifies that all\n \trefs under `$GIT_DIR/refs/heads/` and `$GIT_DIR/refs/tags/`\ndiff --git a/builtin-push.c b/builtin-push.c\nindex c8cb63e..1194800 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -104,6 +104,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \tint dry_run = 0;\n \tint force = 0;\n \tint tags = 0;\n+\tint matching = 0;\n \tconst char *repo = NULL;\t/* default repository */\n \n \tstruct option options[] = {\n@@ -117,6 +118,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tOPT_BOOLEAN( 0 , \"thin\", &thin, \"use thin pack\"),\n \t\tOPT_STRING( 0 , \"receive-pack\", &receivepack, \"receive-pack\", \"receive pack program\"),\n \t\tOPT_STRING( 0 , \"exec\", &receivepack, \"receive-pack\", \"receive pack program\"),\n+\t\tOPT_BOOLEAN('m', \"matching\", &matching, \"push matching refs\"),\n \t\tOPT_END()\n \t};\n \n@@ -134,6 +136,22 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tflags |= TRANSPORT_PUSH_ALL;\n \tif (mirror)\n \t\tflags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);\n+\tif (all && argc > 1)\n+\t\tdie (\"Do you want to push explicit refs or --all?\");\n+\tif (matching && all)\n+\t\tdie (\"--matching and --all are mutually exclusive\");\n+\tif (matching && argc > 1)\n+\t\tdie (\"--matching and explicit refs are mutually exclusive\");\n+\tif (!matching && !all && argc < 2)\n+\t\twarning(\"Pushing without branch names is deprecated.\\n\"\n+\t\t\t\"Too many users just assumed what it should do\\n\"\n+\t\t\t\"according to them, got burned, and blamed us,\\n\"\n+\t\t\t\"the good git developers.\\n\\n\"\n+\t\t\t\"So everybody has to suffer now, and get used to\\n\"\n+\t\t\t\"new semantics.\\n\\n\"\n+\t\t\t\"What used to be default will need the --matching\\n\"\n+\t\t\t\"option in the future.\\n\\n\"\n+\t\t\t\"Thank you for your time.\\n\");\n \n \tif (argc > 0) {\n \t\trepo = argv[0];\n"},{"id":"69294","messageId":"alpine.LSU.1.00.0802191651550.30505@racer.site","threadId":"12183","inReplyTo":"20080219163743.GA31668@sigill.intra.peff.net","subject":"Re: [PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-19T16:54:14Z","receivedAt":"2008-02-19T16:54:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 Feb 2008, Jeff King wrote:\n\n> On Tue, Feb 19, 2008 at 04:14:35PM +0000, Johannes Schindelin wrote:\n> \n> > Subject: [PATCH(TIC)] push: annoy all users by deprecating the default\n> \n> Heh. It is a good sign that git has made the patch-generation workflow \n> so pleasant to use that we are willing to make patches for the sake of \n> humor. :)\n\nYeah, code talks... even humourously ;-)\n\n> > \tFWIW I would resist, just because that config option would change\n> > \tthe _semantics_ of a git program.\n> > \n> > \tJust think about the IRC channel.  \"How do I update only HEAD?\" --\n> > \t\"Just say 'git push'\" -- \"No, that updates nothing\" -- \"Well, \n> > \tworks here\" -- \"But not here!\" ... \"Can _nobody_ help me?\"\n> \n> Just say \"git push origin HEAD\"?\n\nThe point is: if that becomes the default (with a certain config option), \npeople will get used to typing \"git push\".  They will not even _know_ \nabout the explicit form.\n\n> > diff --git a/builtin-push.c b/builtin-push.c\n> > index c8cb63e..7bcb141 100644\n> > --- a/builtin-push.c\n> > +++ b/builtin-push.c\n> > @@ -134,6 +134,14 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n> >  \t\tflags |= TRANSPORT_PUSH_ALL;\n> >  \tif (mirror)\n> >  \t\tflags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);\n> > +\tif (!all && argc < 2)\n> > +\t\twarning(\"Pushing without branch names is deprecated.\\n\"\n> > +\t\t\t\"Too many users just assumed what it should do\\n\"\n> > +\t\t\t\"according to them, got burned, and blamed us,\\n\"\n> > +\t\t\t\"the good git developers.\\n\\n\"\n> > +\t\t\t\"So everybody has to suffer now, and get used to\\n\"\n> > +\t\t\t\"new semantics.\\n\\n\"\n> > +\t\t\t\"Thank you for your time.\\n\");\n> >  \n> >  \tif (argc > 0) {\n> >  \t\trepo = argv[0];\n> \n> You forgot to add a \"--matching\" option in case people want to\n> explicitly request the old behavior. ;P\n\nSee followup.\n\nBTW if that is really the way to go, we will have to have a _long_ period \n(I am talking about 6-12 _months_ if not more) where there _must not_ be a \ndefault action for git-push.  Otherwise people _will_ get more confused \nthan necessary.\n\nCiao,\nDscho\n"},{"id":"69296","messageId":"20080219170507.GA1144@sigill.intra.peff.net","threadId":"12183","inReplyTo":"alpine.LSU.1.00.0802191651550.30505@racer.site","subject":"Re: [PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-19T17:05:07Z","receivedAt":"2008-02-19T17:05:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 19, 2008 at 04:54:14PM +0000, Johannes Schindelin wrote:\n\n> > Just say \"git push origin HEAD\"?\n> \n> The point is: if that becomes the default (with a certain config option), \n> people will get used to typing \"git push\".  They will not even _know_ \n> about the explicit form.\n\nI guess I hoped that people giving answers on the IRC channel would be a\nlittle less clueless. Perhaps that is just optimism.\n\n> See followup.\n\nI'm actually starting to like your patch now...;)\n\n> BTW if that is really the way to go, we will have to have a _long_ period \n> (I am talking about 6-12 _months_ if not more) where there _must not_ be a \n> default action for git-push.  Otherwise people _will_ get more confused \n> than necessary.\n\nI agree that it would need a long deprecation period to change behavior.\nIt would almost be easier to have a \"git <foo>\" command where <foo> is\nsome sort of restricted, safe-for-certain-workflows version of push.\n\n-Peff\n"},{"id":"69300","messageId":"76718490802191040h6b041ae4q7ae3329be82ec902@mail.gmail.com","threadId":"12183","inReplyTo":"20080219163743.GA31668@sigill.intra.peff.net","subject":"Re: [PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-02-19T18:40:14Z","receivedAt":"2008-02-19T18:40:14Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Feb 19, 2008 11:37 AM, Jeff King <peff@peff.net> wrote:\n>\n> Seriously, though, I think it is not just new users. It is that for some\n> (many? most?) people, wanting to push just the HEAD is the _normal_\n> workflow. So they must remember to always say \"git push origin HEAD\",\n> and if they ever forget, the side effects are non-trivial to clean up.\n\n[alias]\n\tmypush = push origin HEAD\n\n(my<cmd> aliases are a lot easier than fighting the powers that be.)\n\n:-)\n\nj.\n"},{"id":"69347","messageId":"5d46db230802191703v1e273284k71817fcd8a2639a1@mail.gmail.com","threadId":"12183","inReplyTo":"20080219170507.GA1144@sigill.intra.peff.net","subject":"Re: [PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Govind Salinas","fromEmail":"blix@sophiasuchtig.com","sentAt":"2008-02-20T01:03:23Z","receivedAt":"2008-02-20T01:03:23Z","isPatch":true,"sender":{"key":"blix@sophiasuchtig.com","avatar":null},"body":"On 2/19/08, Jeff King <peff@peff.net> wrote:\n> On Tue, Feb 19, 2008 at 04:54:14PM +0000, Johannes Schindelin wrote:\n>\n> > > Just say \"git push origin HEAD\"?\n> >\n> > The point is: if that becomes the default (with a certain config option),\n> > people will get used to typing \"git push\".  They will not even _know_\n> > about the explicit form.\n>\n> I guess I hoped that people giving answers on the IRC channel would be a\n> little less clueless. Perhaps that is just optimism.\n>\n> > See followup.\n>\n> I'm actually starting to like your patch now...;)\n>\n> > BTW if that is really the way to go, we will have to have a _long_ period\n> > (I am talking about 6-12 _months_ if not more) where there _must not_ be a\n> > default action for git-push.  Otherwise people _will_ get more confused\n> > than necessary.\n>\n> I agree that it would need a long deprecation period to change behavior.\n> It would almost be easier to have a \"git <foo>\" command where <foo> is\n> some sort of restricted, safe-for-certain-workflows version of push.\n>\n\nFor those interested, this is how I plan to have the default for\npyrite.  The default currently just calls \"git push origin HEAD\"\nCalling with another target repository and refspec would still be\nsupported of course.\n\nIn general, the plan it to take the most common work flows and simply\nthe UI around those.  This includes silently doing \"git add -u\" before\npushing a commit and \"pyt diff\" will diff between the working\ndirectory and HEAD because I have never been interested in the state\nof the index, only in the state of the working dir.\n\n-Govind\n"},{"id":"69350","messageId":"7vr6f8e8lx.fsf@gitster.siamese.dyndns.org","threadId":"12183","inReplyTo":"5d46db230802191703v1e273284k71817fcd8a2639a1@mail.gmail.com","subject":"Re: [PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-20T01:10:02Z","receivedAt":"2008-02-20T01:10:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Govind Salinas\" <blix@sophiasuchtig.com> writes:\n\n> For those interested, this is how I plan to have the default for\n> pyrite.  The default currently just calls \"git push origin HEAD\"\n> Calling with another target repository and refspec would still be\n> supported of course.\n>\n> In general, the plan it to take the most common work flows and simply\n> the UI around those.  This includes silently doing \"git add -u\" before\n> pushing a commit and \"pyt diff\" will diff between the working\n> directory and HEAD because I have never been interested in the state\n> of the index, only in the state of the working dir.\n\nFor both counts, it feels so much like Cogito.\n\nI would not comment on \"the most common\" adjective, but I am\nstill a big believer of \"core git gives common foundation for\nPorcelains that support different workflows to talk with each\nother\" ideal, and I really like that you are building a\nPorcelain that would suit your favorite workflow.\n"},{"id":"69353","messageId":"5d46db230802191721p527c0a85k362c7b364c7e99c4@mail.gmail.com","threadId":"12183","inReplyTo":"7vr6f8e8lx.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Govind Salinas","fromEmail":"blix@sophiasuchtig.com","sentAt":"2008-02-20T01:21:08Z","receivedAt":"2008-02-20T01:21:08Z","isPatch":true,"sender":{"key":"blix@sophiasuchtig.com","avatar":null},"body":"On 2/19/08, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Govind Salinas\" <blix@sophiasuchtig.com> writes:\n>\n> > For those interested, this is how I plan to have the default for\n> > pyrite.  The default currently just calls \"git push origin HEAD\"\n> > Calling with another target repository and refspec would still be\n> > supported of course.\n> >\n> > In general, the plan it to take the most common work flows and simply\n> > the UI around those.  This includes silently doing \"git add -u\" before\n> > pushing a commit and \"pyt diff\" will diff between the working\n> > directory and HEAD because I have never been interested in the state\n> > of the index, only in the state of the working dir.\n>\n> For both counts, it feels so much like Cogito.\n>\n> I would not comment on \"the most common\" adjective, but I am\n> still a big believer of \"core git gives common foundation for\n> Porcelains that support different workflows to talk with each\n> other\" ideal, and I really like that you are building a\n> Porcelain that would suit your favorite workflow.\n>\n>\nOnce I have it in better shape, I hope to get commentary from the rest of the\ngit users on how their workflows go and see where I can simplify things or\nwhere they need to be more complex.  I don't want it to _just_ be for my\nworkflow.  I want something that appeals to the common user (if there is such\na thing, and with git, I don't know that you can say that).\n\n-Govind\n"},{"id":"69357","messageId":"7vmypwe2t5.fsf@gitster.siamese.dyndns.org","threadId":"12183","inReplyTo":"5d46db230802191721p527c0a85k362c7b364c7e99c4@mail.gmail.com","subject":"Re: [PATCH(TIC)] push: annoy all users by deprecating the default semantics","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-20T03:15:18Z","receivedAt":"2008-02-20T03:15:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Govind Salinas\" <blix@sophiasuchtig.com> writes:\n\n> On 2/19/08, Junio C Hamano <gitster@pobox.com> wrote:\n> ...\n>> I would not comment on \"the most common\" adjective, but I am\n>> still a big believer of \"core git gives common foundation for\n>> Porcelains that support different workflows to talk with each\n>> other\" ideal, and I really like that you are building a\n>> Porcelain that would suit your favorite workflow.\n>>\n> ...  I don't want it to _just_ be for my\n> workflow.  I want something that appeals to the common user.\n\nOh, I did not mean \"your private workflow that is not common to\nanybody else\".  That's certainly useless and there is no reason\nI would have said \"I really like\" to something like that (on the\nother hand, of course I would not stop such an attempt either).\n\nThat's why I said \"your _favorite_ workflow\".  Your favorite\ncould certainly be shared by other people.\n"}]}