{"thread":{"id":"10917","subject":"! [rejected] master -> master (non-fast forward)","startedAt":"2007-11-18T15:12:10Z","lastAt":"2007-11-21T07:39:38Z","messageCount":19,"participants":["Jon Smirl","Junio C Hamano","Alex Riesen","Catalin Marinas","Daniel Barkalow","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"60234","messageId":"9e4733910711180712n6ee271fau774310e63ab08f6d@mail.gmail.com","threadId":"10917","inReplyTo":null,"subject":"! [rejected] master -> master (non-fast forward)","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-18T15:12:10Z","receivedAt":"2007-11-18T15:12:10Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"What's causing this? I'm using stgit on the master branch.\nI'm fixing it each time on the remote server by deleting the ref to master.\n\njonsmirl@terra:~/ds$ git push digispeaker\nTo ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git\n ! [rejected] master -> master (non-fast forward)\nerror: failed to push to\n'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git'\njonsmirl@terra:~/ds$\n\nOn the server I have:\n[core]\n repositoryformatversion = 0\n filemode = true\n bare = true\n logallrefupdates = true\n\nbare was set false, I just flipped it to true. The server repo was\noriginally created via a clone from kernel.org and then renamed to be\na bare repo. Why do we need a 'bare' attribute?\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"60241","messageId":"7v7ikfwhkj.fsf@gitster.siamese.dyndns.org","threadId":"10917","inReplyTo":"9e4733910711180712n6ee271fau774310e63ab08f6d@mail.gmail.com","subject":"Re: ! [rejected] master -> master (non-fast forward)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-18T18:10:20Z","receivedAt":"2007-11-18T18:10:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jon Smirl\" writes:\n\n> What's causing this? I'm using stgit on the master branch.\n> I'm fixing it each time on the remote server by deleting the ref to master.\n>\n> jonsmirl@terra:~/ds$ git push digispeaker\n> To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git\n> ! [rejected] master -> master (non-fast forward)\n> error: failed to push to\n> 'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git'\n> jonsmirl@terra:~/ds$\n\nA \"non-fast forward\" means that you had this history earlier:\n\n o---o---A\n /\n ---o\n\npushed \"A\" to the remote's 'master', then built this history:\n\n o---o---A\n /\n ---o---o---o---o---A'\n\nby rewinding and rebuilding, and the tip of the branch now\npoints at A', which you tried to push to the remote.\n\nWhich often causes troubles for people who are fetching from the\nbranch you are pushing into, and forbidden by default as a\nsafety measure.\n\nAs long as the people who fetch from the branch knows that you\nwill regularly rewinding the tip of the branch, there is no\nconfusion, and you can \"force\" a non-fast forward update. There\nare two independent safety mechanisms:\n\n - the sending end safety can be overriden by \"git push --force\"\n and/or by using a refspec prefixed with a '+');\n\n - the receiving end safety can be overriden by the config\n variable receive.denynonfastworwards of the repository you\n are pushing into.\n\nThe latter defaults to \"unsafe\", but if the safety is activated\nin the repository, forcing from the sending side will not\ndeactivate it. IOW, both ends need to agree to allow the unsafe\nbehaviour.\n\n> On the server I have:\n> [core]\n> repositoryformatversion = 0\n> filemode = true\n> bare = true\n> logallrefupdates = true\n>\n> bare was set false, I just flipped it to true. The server repo was\n> originally created via a clone from kernel.org and then renamed to be\n> a bare repo. Why do we need a 'bare' attribute?\n\nThere are a few things that change behaviour depending on the\nbareness of the repository. One example is that \"git fetch\"\nthat updates to the current branch (i.e. what HEAD points at) by\nhaving it as the RHS of a refspec is accepted only for bare\nrepositories (for non-bare repositories such a fetch would make\nthe HEAD and the work tree go out-of-sync).\n"},{"id":"60242","messageId":"20071118182901.GA5939@steel.home","threadId":"10917","inReplyTo":"9e4733910711180712n6ee271fau774310e63ab08f6d@mail.gmail.com","subject":"Re: ! [rejected] master -> master (non-fast forward)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-11-18T18:29:01Z","receivedAt":"2007-11-18T18:29:01Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Jon Smirl, Sun, Nov 18, 2007 16:12:10 +0100:\n> What's causing this? I'm using stgit on the master branch.\n> I'm fixing it each time on the remote server by deleting the ref to master.\n> \n> jonsmirl@terra:~/ds$ git push digispeaker\n> To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git\n> ! [rejected] master -> master (non-fast forward)\n> error: failed to push to\n\nthe branch you are pushing does not fast-forward to the one on\ndigispeaker. IOW, the master on digispeaker has changed since you made\nchanges on your local master.\n"},{"id":"60244","messageId":"9e4733910711181042x123e99efjad38486654db17e2@mail.gmail.com","threadId":"10917","inReplyTo":"7v7ikfwhkj.fsf@gitster.siamese.dyndns.org","subject":"Re: ! [rejected] master -> master (non-fast forward)","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-18T18:42:19Z","receivedAt":"2007-11-18T18:42:19Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/18/07, Junio C Hamano wrote:\n> \"Jon Smirl\" writes:\n>\n> > What's causing this? I'm using stgit on the master branch.\n> > I'm fixing it each time on the remote server by deleting the ref to master.\n> >\n> > jonsmirl@terra:~/ds$ git push digispeaker\n> > To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git\n> > ! [rejected] master -> master (non-fast forward)\n> > error: failed to push to\n> > 'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git'\n> > jonsmirl@terra:~/ds$\n>\n> A \"non-fast forward\" means that you had this history earlier:\n>\n> o---o---A\n> /\n> ---o\n>\n> pushed \"A\" to the remote's 'master', then built this history:\n>\n> o---o---A\n> /\n> ---o---o---o---o---A'\n>\n> by rewinding and rebuilding, and the tip of the branch now\n> points at A', which you tried to push to the remote.\n\nstgit must be doing this when I rebase. It pops all of it's patches,\nmoves to head of linus/master and then rebases them.\n\nI'm the only person with write access to the repo.\n\n> Which often causes troubles for people who are fetching from the\n> branch you are pushing into, and forbidden by default as a\n> safety measure.\n\nWhat is the right way to share repositories using stgit? I have a set\nof patches which I am working on for kernel inclusion. I have them\napplied as a stgit stack on top of linus/master. I need to share this\npatch stack with other developers. These developers may want to change\none of my patches. Right now they are emailing me deltas and I apply\nthem to the appropriate stgit patch. I have seventeen patches in my\nstack currently.\n\nI am starting to see why several people have made comments about\nintegrating stgit into git. When other developers clone my repo the\nstgit setup doesn't come with it. It would be great it we could use\ngit to push the stgit patches around and work on them.\n\n> As long as the people who fetch from the branch knows that you\n> will regularly rewinding the tip of the branch, there is no\n> confusion, and you can \"force\" a non-fast forward update. There\n> are two independent safety mechanisms:\n>\n> - the sending end safety can be overriden by \"git push --force\"\n> and/or by using a refspec prefixed with a '+');\n>\n> - the receiving end safety can be overriden by the config\n> variable receive.denynonfastworwards of the repository you\n> are pushing into.\n>\n> The latter defaults to \"unsafe\", but if the safety is activated\n> in the repository, forcing from the sending side will not\n> deactivate it. IOW, both ends need to agree to allow the unsafe\n> behaviour.\n>\n> > On the server I have:\n> > [core]\n> > repositoryformatversion = 0\n> > filemode = true\n> > bare = true\n> > logallrefupdates = true\n> >\n> > bare was set false, I just flipped it to true. The server repo was\n> > originally created via a clone from kernel.org and then renamed to be\n> > a bare repo. Why do we need a 'bare' attribute?\n>\n> There are a few things that change behaviour depending on the\n> bareness of the repository. One example is that \"git fetch\"\n> that updates to the current branch (i.e. what HEAD points at) by\n> having it as the RHS of a refspec is accepted only for bare\n> repositories (for non-bare repositories such a fetch would make\n> the HEAD and the work tree go out-of-sync).\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"60339","messageId":"tnxbq9qyvom.fsf@pc1117.cambridge.arm.com","threadId":"10917","inReplyTo":"9e4733910711181042x123e99efjad38486654db17e2@mail.gmail.com","subject":"Re: ! [rejected] master -> master (non-fast forward)","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2007-11-19T17:47:05Z","receivedAt":"2007-11-19T17:47:05Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"\"Jon Smirl\" wrote:\n> On 11/18/07, Junio C Hamano wrote:\n>> \"Jon Smirl\" writes:\n>>\n>> > What's causing this? I'm using stgit on the master branch.\n[...]\n>> pushed \"A\" to the remote's 'master', then built this history:\n>>\n>> o---o---A\n>> /\n>> ---o---o---o---o---A'\n>>\n>> by rewinding and rebuilding, and the tip of the branch now\n>> points at A', which you tried to push to the remote.\n>\n> stgit must be doing this when I rebase. It pops all of it's patches,\n> moves to head of linus/master and then rebases them.\n[...]\n> What is the right way to share repositories using stgit? I have a set\n> of patches which I am working on for kernel inclusion. I have them\n> applied as a stgit stack on top of linus/master. I need to share this\n> patch stack with other developers. These developers may want to change\n> one of my patches. Right now they are emailing me deltas and I apply\n> them to the appropriate stgit patch. I have seventeen patches in my\n> stack currently.\n\nStGIT is meant for keeping a clean history but with the big\ndisadvantage that this history is volatile.\n\nA solution is for the other developers to use StGIT or just git-rebase\nso that they always have the same base (volatile) history and keep\ntheir patches on top of yours.\n\nA 2nd approach is to use topic branches rather than StGIT patches but\nyou might lose some flexibility.\n\nYet another approach (which I used) is to keep a public branch (can be\nmaintained by StGIT) where the history doesn't change and a devel\nvolatile branch. When I modify some patches and they are ready for\npublishing, switch to the public branch and cherry-pick them (stg\npick) from the devel branch. Because this is done with a three-way\nmerge in StGIT, you will only get the new changes rather than the full\npatch. You need to change the patch message (as it is that of the\noriginal patch) to describe the specific changes and run 'stg refresh\n&& stg commit' to store it into the immutable history (well, there is\nan 'uncommit' command as well if something goes wrong).\n\n-- \nCatalin\n"},{"id":"60377","messageId":"9e4733910711191454i40d56fa2h9791415c092b9b9c@mail.gmail.com","threadId":"10917","inReplyTo":"tnxbq9qyvom.fsf@pc1117.cambridge.arm.com","subject":"Re: ! [rejected] master -> master (non-fast forward)","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-19T22:54:05Z","receivedAt":"2007-11-19T22:54:05Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/19/07, Catalin Marinas wrote:\n> \"Jon Smirl\" wrote:\n> > On 11/18/07, Junio C Hamano wrote:\n> >> \"Jon Smirl\" writes:\n> >>\n> >> > What's causing this? I'm using stgit on the master branch.\n> [...]\n> >> pushed \"A\" to the remote's 'master', then built this history:\n> >>\n> >> o---o---A\n> >> /\n> >> ---o---o---o---o---A'\n> >>\n> >> by rewinding and rebuilding, and the tip of the branch now\n> >> points at A', which you tried to push to the remote.\n> >\n> > stgit must be doing this when I rebase. It pops all of it's patches,\n> > moves to head of linus/master and then rebases them.\n> [...]\n> > What is the right way to share repositories using stgit? I have a set\n> > of patches which I am working on for kernel inclusion. I have them\n> > applied as a stgit stack on top of linus/master. I need to share this\n> > patch stack with other developers. These developers may want to change\n> > one of my patches. Right now they are emailing me deltas and I apply\n> > them to the appropriate stgit patch. I have seventeen patches in my\n> > stack currently.\n>\n> StGIT is meant for keeping a clean history but with the big\n> disadvantage that this history is volatile.\n>\n> A solution is for the other developers to use StGIT or just git-rebase\n> so that they always have the same base (volatile) history and keep\n> their patches on top of yours.\n>\n> A 2nd approach is to use topic branches rather than StGIT patches but\n> you might lose some flexibility.\n>\n> Yet another approach (which I used) is to keep a public branch (can be\n> maintained by StGIT) where the history doesn't change and a devel\n> volatile branch. When I modify some patches and they are ready for\n> publishing, switch to the public branch and cherry-pick them (stg\n> pick) from the devel branch. Because this is done with a three-way\n> merge in StGIT, you will only get the new changes rather than the full\n> patch. You need to change the patch message (as it is that of the\n> original patch) to describe the specific changes and run 'stg refresh\n> && stg commit' to store it into the immutable history (well, there is\n> an 'uncommit' command as well if something goes wrong).\n\n\nIs a StGit where we can transparently share patches under version\ncontrol in the works?\n\nSomething like this:\nclone repo with stgit\nnormal stg commands work with no setup\nchange a patch\nstg push the repo\n\nI stg pull and the patch is updated.\nI also get rebased forward if the base repo has been updated\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"60383","messageId":"Pine.LNX.4.64.0711191841430.12193@iabervon.org","threadId":"10917","inReplyTo":"9e4733910711191454i40d56fa2h9791415c092b9b9c@mail.gmail.com","subject":"Re: ! [rejected] master -> master (non-fast forward)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-20T00:03:35Z","receivedAt":"2007-11-20T00:03:35Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 19 Nov 2007, Jon Smirl wrote:\n\n> On 11/19/07, Catalin Marinas wrote:\n> > \"Jon Smirl\" wrote:\n> > > On 11/18/07, Junio C Hamano wrote:\n> > >> \"Jon Smirl\" writes:\n> > >>\n> > >> > What's causing this? I'm using stgit on the master branch.\n> > [...]\n> > >> pushed \"A\" to the remote's 'master', then built this history:\n> > >>\n> > >> o---o---A\n> > >> /\n> > >> ---o---o---o---o---A'\n> > >>\n> > >> by rewinding and rebuilding, and the tip of the branch now\n> > >> points at A', which you tried to push to the remote.\n> > >\n> > > stgit must be doing this when I rebase. It pops all of it's patches,\n> > > moves to head of linus/master and then rebases them.\n> > [...]\n> > > What is the right way to share repositories using stgit? I have a set\n> > > of patches which I am working on for kernel inclusion. I have them\n> > > applied as a stgit stack on top of linus/master. I need to share this\n> > > patch stack with other developers. These developers may want to change\n> > > one of my patches. Right now they are emailing me deltas and I apply\n> > > them to the appropriate stgit patch. I have seventeen patches in my\n> > > stack currently.\n> >\n> > StGIT is meant for keeping a clean history but with the big\n> > disadvantage that this history is volatile.\n> >\n> > A solution is for the other developers to use StGIT or just git-rebase\n> > so that they always have the same base (volatile) history and keep\n> > their patches on top of yours.\n> >\n> > A 2nd approach is to use topic branches rather than StGIT patches but\n> > you might lose some flexibility.\n> >\n> > Yet another approach (which I used) is to keep a public branch (can be\n> > maintained by StGIT) where the history doesn't change and a devel\n> > volatile branch. When I modify some patches and they are ready for\n> > publishing, switch to the public branch and cherry-pick them (stg\n> > pick) from the devel branch. Because this is done with a three-way\n> > merge in StGIT, you will only get the new changes rather than the full\n> > patch. You need to change the patch message (as it is that of the\n> > original patch) to describe the specific changes and run 'stg refresh\n> > && stg commit' to store it into the immutable history (well, there is\n> > an 'uncommit' command as well if something goes wrong).\n> \n> \n> Is a StGit where we can transparently share patches under version\n> control in the works?\n> \n> Something like this:\n> clone repo with stgit\n> normal stg commands work with no setup\n> change a patch\n> stg push the repo\n> \n> I stg pull and the patch is updated.\n> I also get rebased forward if the base repo has been updated\n\nI've been thinking vaguely about support for essentially version \ncontrolling a quilt series, with the fundamental idea being that the \nhistory of the branch you're working on is a sequence of states of the \nseries, with magic for having both the series specification and the final \nstate in each commit.\n\nNote that this is a different concept from stgit (and, I think, guilt), \nwhich uses the git engine as the magic behind the quilt-like operation, \nmeaning that the history of the commit at the end of the series goes back \nthrough the patches in the series, not back through the changes to the \nseries.\n\nI've got a bunch of ideas on the subject, but I don't really have the \nquilt experience to know how to make this useful to people who want to do \nthis kind of thing. My dream, from the perspective of a user of the \nresults of somebody else's use of this feature, would be being able to \nbisect -mm to determine first that -mm stopped working when Andrew updated \na particular tree, and then bisect within that tree (in each case \ngenerating the test tree with the complete -mm series, but with that \ntree's patch series being from the test point).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"60386","messageId":"20071120041620.GA23566@sigill.intra.peff.net","threadId":"10917","inReplyTo":"20071118182901.GA5939@steel.home","subject":"Re: ! [rejected] master -> master (non-fast forward)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-20T04:16:20Z","receivedAt":"2007-11-20T04:16:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 18, 2007 at 07:29:01PM +0100, Alex Riesen wrote:\n\n> > jonsmirl@terra:~/ds$ git push digispeaker\n> > To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git\n> > ! [rejected] master -> master (non-fast forward)\n> > error: failed to push to\n> \n> the branch you are pushing does not fast-forward to the one on\n> digispeaker. IOW, the master on digispeaker has changed since you made\n> changes on your local master.\n\nAlex, are you going to rework your \"consolidate nonff errors and print a\nmore extended message\" patch on top of what's in next (I think it should\nbe much simpler now).\n\n-Peff\n"},{"id":"60393","messageId":"20071120065021.GA4172@steel.home","threadId":"10917","inReplyTo":"20071120041620.GA23566@sigill.intra.peff.net","subject":"Re: ! [rejected] master -> master (non-fast forward)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-11-20T06:50:21Z","receivedAt":"2007-11-20T06:50:21Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Jeff King, Tue, Nov 20, 2007 05:16:20 +0100:\n> On Sun, Nov 18, 2007 at 07:29:01PM +0100, Alex Riesen wrote:\n> \n> > > jonsmirl@terra:~/ds$ git push digispeaker\n> > > To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git\n> > > ! [rejected] master -> master (non-fast forward)\n> > > error: failed to push to\n> > \n> > the branch you are pushing does not fast-forward to the one on\n> > digispeaker. IOW, the master on digispeaker has changed since you made\n> > changes on your local master.\n> \n> Alex, are you going to rework your \"consolidate nonff errors and print a\n> more extended message\" patch on top of what's in next (I think it should\n> be much simpler now).\n\nDo you mean that \"Beautify the output of send-pack a bit\", Message-ID:\n<20071112221140.GD2918@steel.home>?\n\nIf so, I'm confused. Didn't you already do that in your recent\n\"send-pack:\" patch series? It looked to me as if you did (except for\nthe hint regarding non-ff branches to be updated everything is there).\n"},{"id":"60401","messageId":"20071120111317.GA4120@sigill.intra.peff.net","threadId":"10917","inReplyTo":"20071120065021.GA4172@steel.home","subject":"Re: ! [rejected] master -> master (non-fast forward)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-20T11:13:18Z","receivedAt":"2007-11-20T11:13:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 20, 2007 at 07:50:21AM +0100, Alex Riesen wrote:\n\n> > Alex, are you going to rework your \"consolidate nonff errors and print a\n> > more extended message\" patch on top of what's in next (I think it should\n> > be much simpler now).\n> \n> Do you mean that \"Beautify the output of send-pack a bit\", Message-ID:\n> <20071112221140.GD2918@steel.home>?\n> \n> If so, I'm confused. Didn't you already do that in your recent\n> \"send-pack:\" patch series? It looked to me as if you did (except for\n> the hint regarding non-ff branches to be updated everything is there).\n\nThat is what I meant. In the current code, the errors aren't\nconsolidated at the end, and as you mentioned, we don't print the extra\nmessage. Two patch series follows (but see comments on each patch).\n\n-Peff\n"},{"id":"60402","messageId":"20071120111801.GA7814@sigill.intra.peff.net","threadId":"10917","inReplyTo":"20071120111317.GA4120@sigill.intra.peff.net","subject":"[PATCH 1/2] send-pack: cluster ref status reporting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-20T11:18:01Z","receivedAt":"2007-11-20T11:18:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Instead of intermingling success and failure, we now print:\n\n 1. all uptodate refs (if args.verbose is enabled)\n 2. successfully pushed refs\n 3. failed refs\n\nwith the assumption that the user is most likely to see the\nones at the end, and therefore we order them from \"least\ninteresting\" to \"most interesting.\"\n\nSigned-off-by: Jeff King \n---\nI am somewhat ambivalent on this patch. In most cases, it won't make a\ndifference, since the output is small enough. For large pushes, it might\nbe better to have errors at the end. OTOH, you do still get \"error:\nfailed to push to ...\" at the end, and you can scroll up and see the\nerrors if you like. And it's not like preserving the original ref output\norder was all that interesting.\n\n builtin-send-pack.c | 93 +++++++++++++++++++++++++++++----------------------\n 1 files changed, 53 insertions(+), 40 deletions(-)\n\ndiff --git a/builtin-send-pack.c b/builtin-send-pack.c\nindex 3ce218f..f1cdb97 100644\n--- a/builtin-send-pack.c\n+++ b/builtin-send-pack.c\n@@ -298,52 +298,65 @@ static void print_ok_ref_status(struct ref *ref)\n \t}\n }\n \n+static int print_one_push_status(struct ref *ref, const char *dest, int count)\n+{\n+\tif (!count)\n+\t\tfprintf(stderr, \"To %s\\n\", dest);\n+\n+\tswitch(ref->status) {\n+\tcase REF_STATUS_NONE:\n+\t\tprint_ref_status('X', \"[no match]\", ref, NULL, NULL);\n+\t\tbreak;\n+\tcase REF_STATUS_REJECT_NODELETE:\n+\t\tprint_ref_status('!', \"[rejected]\", ref, NULL,\n+\t\t\t\t\"remote does not support deleting refs\");\n+\t\tbreak;\n+\tcase REF_STATUS_UPTODATE:\n+\t\tprint_ref_status('=', \"[up to date]\", ref,\n+\t\t\t\tref->peer_ref, NULL);\n+\t\tbreak;\n+\tcase REF_STATUS_REJECT_NONFASTFORWARD:\n+\t\tprint_ref_status('!', \"[rejected]\", ref, ref->peer_ref,\n+\t\t\t\t\"non-fast forward\");\n+\t\tbreak;\n+\tcase REF_STATUS_REMOTE_REJECT:\n+\t\tprint_ref_status('!', \"[remote rejected]\", ref,\n+\t\t\t\tref->deletion ? ref->peer_ref : NULL,\n+\t\t\t\tref->remote_status);\n+\t\tbreak;\n+\tcase REF_STATUS_EXPECTING_REPORT:\n+\t\tprint_ref_status('!', \"[remote failure]\", ref,\n+\t\t\t\tref->deletion ? ref->peer_ref : NULL,\n+\t\t\t\t\"remote failed to report status\");\n+\t\tbreak;\n+\tcase REF_STATUS_OK:\n+\t\tprint_ok_ref_status(ref);\n+\t\tbreak;\n+\t}\n+\n+\treturn 1;\n+}\n+\n static void print_push_status(const char *dest, struct ref *refs)\n {\n \tstruct ref *ref;\n-\tint shown_dest = 0;\n+\tint n = 0;\n \n-\tfor (ref = refs; ref; ref = ref->next) {\n-\t\tif (!ref->status)\n-\t\t\tcontinue;\n-\t\tif (ref->status == REF_STATUS_UPTODATE && !args.verbose)\n-\t\t\tcontinue;\n+\tif (args.verbose) {\n+\t\tfor (ref = refs; ref; ref = ref->next)\n+\t\t\tif (ref->status == REF_STATUS_UPTODATE)\n+\t\t\t\tn += print_one_push_status(ref, dest, n);\n+\t}\n \n-\t\tif (!shown_dest) {\n-\t\t\tfprintf(stderr, \"To %s\\n\", dest);\n-\t\t\tshown_dest = 1;\n-\t\t}\n+\tfor (ref = refs; ref; ref = ref->next)\n+\t\tif (ref->status == REF_STATUS_OK)\n+\t\t\tn += print_one_push_status(ref, dest, n);\n \n-\t\tswitch(ref->status) {\n-\t\tcase REF_STATUS_NONE:\n-\t\t\tprint_ref_status('X', \"[no match]\", ref, NULL, NULL);\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_REJECT_NODELETE:\n-\t\t\tprint_ref_status('!', \"[rejected]\", ref, NULL,\n-\t\t\t\t\t\"remote does not support deleting refs\");\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_UPTODATE:\n-\t\t\tprint_ref_status('=', \"[up to date]\", ref,\n-\t\t\t\t\tref->peer_ref, NULL);\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_REJECT_NONFASTFORWARD:\n-\t\t\tprint_ref_status('!', \"[rejected]\", ref, ref->peer_ref,\n-\t\t\t\t\t\"non-fast forward\");\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_REMOTE_REJECT:\n-\t\t\tprint_ref_status('!', \"[remote rejected]\", ref,\n-\t\t\t\t\tref->deletion ? ref->peer_ref : NULL,\n-\t\t\t\t\tref->remote_status);\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_EXPECTING_REPORT:\n-\t\t\tprint_ref_status('!', \"[remote failure]\", ref,\n-\t\t\t\t\tref->deletion ? ref->peer_ref : NULL,\n-\t\t\t\t\t\"remote failed to report status\");\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_OK:\n-\t\t\tprint_ok_ref_status(ref);\n-\t\t\tbreak;\n-\t\t}\n+\tfor (ref = refs; ref; ref = ref->next) {\n+\t\tif (ref->status != REF_STATUS_NONE &&\n+\t\t ref->status != REF_STATUS_UPTODATE &&\n+\t\t ref->status != REF_STATUS_OK)\n+\t\t\tn += print_one_push_status(ref, dest, n);\n \t}\n }\n \n-- \n1.5.3.6.1784.gd1b1d-dirty\n"},{"id":"60403","messageId":"20071120112146.GB7814@sigill.intra.peff.net","threadId":"10917","inReplyTo":"20071120111317.GA4120@sigill.intra.peff.net","subject":"[PATCH 2/2] send-pack: print \"maybe you need to pull\" hint","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-20T11:21:46Z","receivedAt":"2007-11-20T11:21:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"If there were refs rejected for not being fastforwards, then\nwe used to print a \"maybe you are not up-to-date\" hint. This\nwas lost in the recent terse-output patches.\n\nSigned-off-by: Jeff King \n---\nI am slightly negative on this patch, just because I always found that\nparticular warning a bit ugly (and the new output is so nice and\ncompact). But for new users, perhaps the extra hint is helpful?\n\nIf we do want the warning, then other options include:\n - listing each non-fast forward, as Alex's original patch did; this\n seems kind of pointless given that they are clustered at the bottom\n already\n - possibly cluster non-fast forwards differently from other errors in\n the output\n - tweak the text\n\n builtin-send-pack.c | 9 +++++++++\n 1 files changed, 9 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-send-pack.c b/builtin-send-pack.c\nindex f1cdb97..4bfa847 100644\n--- a/builtin-send-pack.c\n+++ b/builtin-send-pack.c\n@@ -341,6 +341,7 @@ static void print_push_status(const char *dest, struct ref *refs)\n {\n \tstruct ref *ref;\n \tint n = 0;\n+\tint nonff = 0;\n \n \tif (args.verbose) {\n \t\tfor (ref = refs; ref; ref = ref->next)\n@@ -357,7 +358,15 @@ static void print_push_status(const char *dest, struct ref *refs)\n \t\t ref->status != REF_STATUS_UPTODATE &&\n \t\t ref->status != REF_STATUS_OK)\n \t\t\tn += print_one_push_status(ref, dest, n);\n+\t\tif (ref->status == REF_STATUS_REJECT_NONFASTFORWARD)\n+\t\t\tnonff++;\n \t}\n+\n+\tif (nonff)\n+\t\terror(\"%d remote refs were not ancestors of their \"\n+\t\t \"corresponding local ref\\n\"\n+\t\t \"Maybe you are not up-to-date and need to pull first?\",\n+\t\t nonff);\n }\n \n static int refs_pushed(struct ref *ref)\n-- \n1.5.3.6.1784.gd1b1d-dirty\n"},{"id":"60420","messageId":"20071120182233.GA3461@steel.home","threadId":"10917","inReplyTo":"20071120111801.GA7814@sigill.intra.peff.net","subject":"Re: [PATCH 1/2] send-pack: cluster ref status reporting","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-11-20T18:22:33Z","receivedAt":"2007-11-20T18:22:33Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Jeff King, Tue, Nov 20, 2007 12:18:01 +0100:\n> Instead of intermingling success and failure, we now print:\n> \n> 1. all uptodate refs (if args.verbose is enabled)\n> 2. successfully pushed refs\n> 3. failed refs\n\nI vote for this. The non-ff refs clustered together was the real\nreason behind my beautification patch.\n\n> I am somewhat ambivalent on this patch. In most cases, it won't make a\n> difference, since the output is small enough. For large pushes, it might\n> be better to have errors at the end. OTOH, you do still get \"error:\n> failed to push to ...\" at the end, and you can scroll up and see the\n> errors if you like. And it's not like preserving the original ref output\n> order was all that interesting.\n\nIt is just simplier to distinguish visually: non-ff's are formatted\nsignificantly different. You don't even have to read what is written\nto immediately notice if there are problems.\n"},{"id":"60421","messageId":"20071120182439.GB3461@steel.home","threadId":"10917","inReplyTo":"20071120112146.GB7814@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] send-pack: print \"maybe you need to pull\" hint","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-11-20T18:24:39Z","receivedAt":"2007-11-20T18:24:39Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Jeff King, Tue, Nov 20, 2007 12:21:46 +0100:\n> If there were refs rejected for not being fastforwards, then\n> we used to print a \"maybe you are not up-to-date\" hint. This\n> was lost in the recent terse-output patches.\n> \n> Signed-off-by: Jeff King \n> ---\n> I am slightly negative on this patch, just because I always found that\n> particular warning a bit ugly (and the new output is so nice and\n> compact). But for new users, perhaps the extra hint is helpful?\n\nDunno. It's kind of dumb hint and it takes lots of space. I was even\nthinking about hint(const char *,...), which can be configured to\ncompile out in Makefile.\n"},{"id":"60471","messageId":"7v1wakhxh4.fsf@gitster.siamese.dyndns.org","threadId":"10917","inReplyTo":"20071120111801.GA7814@sigill.intra.peff.net","subject":"Re: [PATCH 1/2] send-pack: cluster ref status reporting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-21T07:24:55Z","receivedAt":"2007-11-21T07:24:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> +static int print_one_push_status(struct ref *ref, const char *dest, int count)\n> +{\n> ...\n> +\tcase REF_STATUS_REMOTE_REJECT:\n> +\t\tprint_ref_status('!', \"[remote rejected]\", ref,\n> +\t\t\t\tref->deletion ? ref->peer_ref : NULL,\n> +\t\t\t\tref->remote_status);\n> +\t\tbreak;\n> +\tcase REF_STATUS_EXPECTING_REPORT:\n> +\t\tprint_ref_status('!', \"[remote failure]\", ref,\n> +\t\t\t\tref->deletion ? ref->peer_ref : NULL,\n> +\t\t\t\t\"remote failed to report status\");\n> +\t\tbreak;\n\nEh,... in ref->deletion mode, the peer_ref is...\n"},{"id":"60472","messageId":"20071121073332.GA10244@sigill.intra.peff.net","threadId":"10917","inReplyTo":"7v1wakhxh4.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] send-pack: cluster ref status reporting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-21T07:33:32Z","receivedAt":"2007-11-21T07:33:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 20, 2007 at 11:24:55PM -0800, Junio C Hamano wrote:\n\n> > +\tcase REF_STATUS_REMOTE_REJECT:\n> > +\t\tprint_ref_status('!', \"[remote rejected]\", ref,\n> > +\t\t\t\tref->deletion ? ref->peer_ref : NULL,\n> > +\t\t\t\tref->remote_status);\n> > +\t\tbreak;\n> > +\tcase REF_STATUS_EXPECTING_REPORT:\n> > +\t\tprint_ref_status('!', \"[remote failure]\", ref,\n> > +\t\t\t\tref->deletion ? ref->peer_ref : NULL,\n> > +\t\t\t\t\"remote failed to report status\");\n> > +\t\tbreak;\n> \n> Eh,... in ref->deletion mode, the peer_ref is...\n\nGah, sorry. This crept in because I based it on the previous, broken\nversion of the other patch series which had the same problem (and\nobviously this chunk is just a pure code move + reindent).\n\nBut pretend like it was competently prepared and give your comments on\nthe idea. ;)\n\n-Peff\n"},{"id":"60473","messageId":"7vwsscgie2.fsf@gitster.siamese.dyndns.org","threadId":"10917","inReplyTo":"20071121073332.GA10244@sigill.intra.peff.net","subject":"Re: [PATCH 1/2] send-pack: cluster ref status reporting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-21T07:36:05Z","receivedAt":"2007-11-21T07:36:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Gah, sorry. This crept in because I based it on the previous, broken\n> version of the other patch series which had the same problem (and\n> obviously this chunk is just a pure code move + reindent).\n>\n> But pretend like it was competently prepared and give your comments on\n> the idea. ;)\n\nHeh, at least I've privately queued it at the tip of\njk/send-pack for review but not merged it to 'next' yet, after\nfixing it up (the last round I also fixed up so that was partly\nwhy I noticed -- the patch did not apply).\n\nThe idea feels sound, and code under cursory look was fine.\n"},{"id":"60475","messageId":"20071121073700.GA10742@sigill.intra.peff.net","threadId":"10917","inReplyTo":"20071121073332.GA10244@sigill.intra.peff.net","subject":"Re: [PATCH 1/2] send-pack: cluster ref status reporting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-21T07:37:01Z","receivedAt":"2007-11-21T07:37:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 21, 2007 at 02:33:32AM -0500, Jeff King wrote:\n\n> > > +\tcase REF_STATUS_REMOTE_REJECT:\n> > > +\t\tprint_ref_status('!', \"[remote rejected]\", ref,\n> > > +\t\t\t\tref->deletion ? ref->peer_ref : NULL,\n> > > +\t\t\t\tref->remote_status);\n> > > +\t\tbreak;\n> \n> Gah, sorry. This crept in because I based it on the previous, broken\n> version of the other patch series which had the same problem (and\n> obviously this chunk is just a pure code move + reindent).\n\nYou will also find that it doesn't apply cleanly to 'next', since it\nattempts to remove the bogus version of the lines (while you correctly\nfixed them up when you applied to 'next').\n\nBelow is a fixed version of the patch for convenience.\n\n-- >8 --\nsend-pack: cluster ref status reporting\n\nInstead of intermingling success and failure, we now print:\n\n 1. all uptodate refs (if args.verbose is enabled)\n 2. successfully pushed refs\n 3. failed refs\n\nwith the assumption that the user is most likely to see the\nones at the end, and therefore we order them from \"least\ninteresting\" to \"most interesting.\"\n---\n builtin-send-pack.c | 93 +++++++++++++++++++++++++++++----------------------\n 1 files changed, 53 insertions(+), 40 deletions(-)\n\ndiff --git a/builtin-send-pack.c b/builtin-send-pack.c\nindex 3aab89c..25ae1fe 100644\n--- a/builtin-send-pack.c\n+++ b/builtin-send-pack.c\n@@ -298,52 +298,65 @@ static void print_ok_ref_status(struct ref *ref)\n \t}\n }\n \n+static int print_one_push_status(struct ref *ref, const char *dest, int count)\n+{\n+\tif (!count)\n+\t\tfprintf(stderr, \"To %s\\n\", dest);\n+\n+\tswitch(ref->status) {\n+\tcase REF_STATUS_NONE:\n+\t\tprint_ref_status('X', \"[no match]\", ref, NULL, NULL);\n+\t\tbreak;\n+\tcase REF_STATUS_REJECT_NODELETE:\n+\t\tprint_ref_status('!', \"[rejected]\", ref, NULL,\n+\t\t\t\t\"remote does not support deleting refs\");\n+\t\tbreak;\n+\tcase REF_STATUS_UPTODATE:\n+\t\tprint_ref_status('=', \"[up to date]\", ref,\n+\t\t\t\tref->peer_ref, NULL);\n+\t\tbreak;\n+\tcase REF_STATUS_REJECT_NONFASTFORWARD:\n+\t\tprint_ref_status('!', \"[rejected]\", ref, ref->peer_ref,\n+\t\t\t\t\"non-fast forward\");\n+\t\tbreak;\n+\tcase REF_STATUS_REMOTE_REJECT:\n+\t\tprint_ref_status('!', \"[remote rejected]\", ref,\n+\t\t\t\tref->deletion ? NULL : ref->peer_ref,\n+\t\t\t\tref->remote_status);\n+\t\tbreak;\n+\tcase REF_STATUS_EXPECTING_REPORT:\n+\t\tprint_ref_status('!', \"[remote failure]\", ref,\n+\t\t\t\tref->deletion ? NULL : ref->peer_ref,\n+\t\t\t\t\"remote failed to report status\");\n+\t\tbreak;\n+\tcase REF_STATUS_OK:\n+\t\tprint_ok_ref_status(ref);\n+\t\tbreak;\n+\t}\n+\n+\treturn 1;\n+}\n+\n static void print_push_status(const char *dest, struct ref *refs)\n {\n \tstruct ref *ref;\n-\tint shown_dest = 0;\n+\tint n = 0;\n \n-\tfor (ref = refs; ref; ref = ref->next) {\n-\t\tif (!ref->status)\n-\t\t\tcontinue;\n-\t\tif (ref->status == REF_STATUS_UPTODATE && !args.verbose)\n-\t\t\tcontinue;\n+\tif (args.verbose) {\n+\t\tfor (ref = refs; ref; ref = ref->next)\n+\t\t\tif (ref->status == REF_STATUS_UPTODATE)\n+\t\t\t\tn += print_one_push_status(ref, dest, n);\n+\t}\n \n-\t\tif (!shown_dest) {\n-\t\t\tfprintf(stderr, \"To %s\\n\", dest);\n-\t\t\tshown_dest = 1;\n-\t\t}\n+\tfor (ref = refs; ref; ref = ref->next)\n+\t\tif (ref->status == REF_STATUS_OK)\n+\t\t\tn += print_one_push_status(ref, dest, n);\n \n-\t\tswitch(ref->status) {\n-\t\tcase REF_STATUS_NONE:\n-\t\t\tprint_ref_status('X', \"[no match]\", ref, NULL, NULL);\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_REJECT_NODELETE:\n-\t\t\tprint_ref_status('!', \"[rejected]\", ref, NULL,\n-\t\t\t\t\t\"remote does not support deleting refs\");\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_UPTODATE:\n-\t\t\tprint_ref_status('=', \"[up to date]\", ref,\n-\t\t\t\t\tref->peer_ref, NULL);\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_REJECT_NONFASTFORWARD:\n-\t\t\tprint_ref_status('!', \"[rejected]\", ref, ref->peer_ref,\n-\t\t\t\t\t\"non-fast forward\");\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_REMOTE_REJECT:\n-\t\t\tprint_ref_status('!', \"[remote rejected]\", ref,\n-\t\t\t\t\tref->deletion ? NULL : ref->peer_ref,\n-\t\t\t\t\tref->remote_status);\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_EXPECTING_REPORT:\n-\t\t\tprint_ref_status('!', \"[remote failure]\", ref,\n-\t\t\t\t\tref->deletion ? NULL : ref->peer_ref,\n-\t\t\t\t\t\"remote failed to report status\");\n-\t\t\tbreak;\n-\t\tcase REF_STATUS_OK:\n-\t\t\tprint_ok_ref_status(ref);\n-\t\t\tbreak;\n-\t\t}\n+\tfor (ref = refs; ref; ref = ref->next) {\n+\t\tif (ref->status != REF_STATUS_NONE &&\n+\t\t ref->status != REF_STATUS_UPTODATE &&\n+\t\t ref->status != REF_STATUS_OK)\n+\t\t\tn += print_one_push_status(ref, dest, n);\n \t}\n }\n \n-- \n1.5.3.6.1786.g2e199\n"},{"id":"60476","messageId":"20071121073938.GB10742@sigill.intra.peff.net","threadId":"10917","inReplyTo":"7vwsscgie2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] send-pack: cluster ref status reporting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-21T07:39:38Z","receivedAt":"2007-11-21T07:39:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 20, 2007 at 11:36:05PM -0800, Junio C Hamano wrote:\n\n> Heh, at least I've privately queued it at the tip of\n> jk/send-pack for review but not merged it to 'next' yet, after\n> fixing it up (the last round I also fixed up so that was partly\n> why I noticed -- the patch did not apply).\n\nOK, good. I should have noticed because I also ran across the same patch\nfailure when I did a rebase earlier today, but I didn't consider that\nthe mistake had slipped out of my repo. :) Sorry for the confusion.\n\n> The idea feels sound, and code under cursory look was fine.\n\nI think it is probably worth applying then. It is slightly more useful\nto the user, and I haven't been able to see any downside.\n\n-Peff\n"}]}