{"thread":{"id":"23942","subject":"rebase --continue confusion","startedAt":"2010-05-30T00:59:01Z","lastAt":"2010-06-07T00:41:46Z","messageCount":12,"participants":["Dale Rowley","Tim Visher","skillzero@gmail.com","Junio C Hamano","Ramkumar Ramachandra","Jan Krüger","Eli Barzilay","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"142548","messageId":"4C01B855.7080409@gmail.com","threadId":"23942","inReplyTo":null,"subject":"rebase --continue confusion","fromName":"Dale Rowley","fromEmail":"ddrowley@gmail.com","sentAt":"2010-05-30T00:59:01Z","receivedAt":"2010-05-30T00:59:01Z","isPatch":false,"sender":{"key":"ddrowley@gmail.com","avatar":null},"body":"I ran into a conflict while running 'git rebase branch1 branch2'. So I edited\nthe file and resolved the conflicts, and then ran 'git add ; git rebase\n--continue'. This printed out a message 'No changes - did you forget to use git\nadd?'. I thought 'No, I'm pretty sure I ran git add' and I assumed I had run\ninto a bug in git because I didn't see how this conflict was different than any\nothers I had successfully resolved. The next time this problem came up, the\nlight finally came on and I realized that I should just run 'git rebase --skip'\nbecause when I resolved the conflicts, I had basically undone all changes that\nthe patch would introduce.\n\nOK, so there isn't a bug in git, but since then I've seen co-workers stumped by\nthis same problem. So maybe it would help to clarify the message? Maybe\nsomething like \"The index is in the same state as it was before the patch was\napplied - refusing to make an empty commit. Did you forget to use 'git add'? Or\nmaybe you should use 'git rebase --skip'?\"\n\n\nDale\n"},{"id":"142570","messageId":"AANLkTika8osPqvlcZKqVTMN5IwLxBZioBCD1NgLHj0EQ@mail.gmail.com","threadId":"23942","inReplyTo":"4C01B855.7080409@gmail.com","subject":"Re: rebase --continue confusion","fromName":"Tim Visher","fromEmail":"tim.visher@gmail.com","sentAt":"2010-05-30T12:44:29Z","receivedAt":"2010-05-30T12:44:29Z","isPatch":false,"sender":{"key":"tim.visher@gmail.com","avatar":"https://gravatar.com/avatar/98307ce54bcac1a46b5d845827d5386e2a27895ff08790cdd3877ad527760575?d=mp&s=160"},"body":"On Sat, May 29, 2010 at 8:59 PM, Dale Rowley wrote:\n> I ran into a conflict while running 'git rebase branch1 branch2'. So I edited\n> the file and resolved the conflicts, and then ran 'git add ; git rebase\n> --continue'. This printed out a message 'No changes - did you forget to use git\n> add?'. I thought 'No, I'm pretty sure I ran git add' and I assumed I had run\n> into a bug in git because I didn't see how this conflict was different than any\n> others I had successfully resolved. The next time this problem came up, the\n> light finally came on and I realized that I should just run 'git rebase --skip'\n> because when I resolved the conflicts, I had basically undone all changes that\n> the patch would introduce.\n>\n> OK, so there isn't a bug in git, but since then I've seen co-workers stumped by\n> this same problem. So maybe it would help to clarify the message? Maybe\n> something like \"The index is in the same state as it was before the patch was\n> applied - refusing to make an empty commit. Did you forget to use 'git add'? Or\n> maybe you should use 'git rebase --skip'?\"\n\n2 things.\n\n1. I agree that the message could be more informative, especially\ngiven the context. If the the patch looks exactly like the last patch\napplied now that you've edited it during a rebase, it would _almost_\nbe safe to assume that you meant to skip and just didn't know you were\ngoing to before hand.\n\n2. `git status` should show you that you had nothing to commit, which\nwould completely explain why `git rebase --continue` threw out the\nmessage it did. I'm in the habit of running `git st` continually and\nit often helps me catch this sort of thing where I thought I'd added\nsomething to the index or forgot that I'd changed some file between\nthe last time I'd updated the index or something along those lines.\nThis is just sort of a recommendation on a way to modify your work\nflow that may help you and your coworkers in the future. YMMV.\n\n-- \n\nIn Christ,\n\nTimmy V.\n\nhttp://burningones.com/\nhttp://five.sentenc.es/ - Spend less time on e-mail\n"},{"id":"142597","messageId":"AANLkTinjyaIndGmu1yiJI_Nwbyq3pB5ef0w9BgDmDpeh@mail.gmail.com","threadId":"23942","inReplyTo":"4C01B855.7080409@gmail.com","subject":"Re: rebase --continue confusion","fromName":"","fromEmail":"skillzero@gmail.com","sentAt":"2010-05-31T00:14:36Z","receivedAt":"2010-05-31T00:14:36Z","isPatch":false,"sender":{"key":"skillzero@gmail.com","avatar":null},"body":"On Sat, May 29, 2010 at 5:59 PM, Dale Rowley wrote:\n> I ran into a conflict while running 'git rebase branch1 branch2'. So I edited\n> the file and resolved the conflicts, and then ran 'git add ; git rebase\n> --continue'. This printed out a message 'No changes - did you forget to use git\n> add?'. I thought 'No, I'm pretty sure I ran git add' and I assumed I had run\n> into a bug in git because I didn't see how this conflict was different than any\n> others I had successfully resolved. The next time this problem came up, the\n> light finally came on and I realized that I should just run 'git rebase --skip'\n> because when I resolved the conflicts, I had basically undone all changes that\n> the patch would introduce.\n>\n> OK, so there isn't a bug in git, but since then I've seen co-workers stumped by\n> this same problem. So maybe it would help to clarify the message? Maybe\n> something like \"The index is in the same state as it was before the patch was\n> applied - refusing to make an empty commit. Did you forget to use 'git add'? Or\n> maybe you should use 'git rebase --skip'?\"\n\nI agree. I actually wasn't as smart as you when I saw that message in\nthe past. I didn't know what the problem was and I didn't know about\ngit rebase --skip (or I probably ignored it when I tried git rebase -h\nsince skipping didn't sound like what I wanted at the time, but thanks\nfor pointing it out if run into this in the future). I think I'd like\ngit to just skip automatically in this case.\n"},{"id":"142619","messageId":"7vwrujzx3t.fsf@alter.siamese.dyndns.org","threadId":"23942","inReplyTo":"20100530101926.3bac34c8jk@jk.gs@perceptron","subject":"Re: [PATCH] git-am: suggest what to do with superfluous patches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-31T19:31:50Z","receivedAt":"2010-05-31T19:31:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan Krüger writes:\n\n> Particularly in the context of rebase, conflicts frequently occur\n> because the change in the patch to be applied was made obsolete by new\n> upstream commits. In this case, solving the conflict effectively means\n> skipping the patch. However, it's not always readily apparent that the\n> patch needs to be skipped, and when people solve the conflict and try\n> git rebase --continue, they get confronted with a message of\n>\n> No changes - did you forget to use 'git add'?\n>\n> That's not very helpful if you did actually stage your changes and they\n> happen to turn the patch into a no-op. This extends the message to point\n> out what's going on.\n>\n> Signed-off-by: Jan Krüger \n> ---\n\nI think this is a change in a good direction; we _might_ want to allow\nthis squelched with \"advice.*\" configuration, but my gut feeling is that\nit wouldn't probably matter much, as it is rather rare to trigger this.\n\n> diff --git a/git-am.sh b/git-am.sh\n> index 87ffae2..43ea52c 100755\n> --- a/git-am.sh\n> +++ b/git-am.sh\n> @@ -726,6 +726,8 @@ do\n> \t\tresolved=\n> \t\tgit diff-index --quiet --cached HEAD -- && {\n> \t\t\techo \"No changes - did you forget to use 'git add'?\"\n> +\t\t\techo \"If there is nothing left to stage, chances are that something else\"\n> +\t\t\techo \"already introduced the same changes; you might want to skip this patch.\"\n\nThe exact wording I'd let people to fight out, but I think this is\nprobably better than Ramkumar's one that says \"if you dropped\". The user\nmay not know that he is doing an equivalent of dropping as a side effect\nof the new base that had accepted the same change, and your message nudges\nthe reader to realize that.\n"},{"id":"142621","messageId":"AANLkTinRafLwhzxUuijdBzfzxLtTb_ua3aM1IxVCCgfa@mail.gmail.com","threadId":"23942","inReplyTo":"7vwrujzx3t.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-am: suggest what to do with superfluous patches","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-05-31T20:17:49Z","receivedAt":"2010-05-31T20:17:49Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Junio,\n\nJunio C Hamano wrote:\n> Jan Krüger writes:\n>> diff --git a/git-am.sh b/git-am.sh\n>> index 87ffae2..43ea52c 100755\n>> --- a/git-am.sh\n>> +++ b/git-am.sh\n>> @@ -726,6 +726,8 @@ do\n>>               resolved=\n>>               git diff-index --quiet --cached HEAD -- && {\n>>                       echo \"No changes - did you forget to use 'git add'?\"\n>> +                     echo \"If there is nothing left to stage, chances are that something else\"\n>> +                     echo \"already introduced the same changes; you might want to skip this patch.\"\n>\n> The exact wording I'd let people to fight out, but I think this is\n> probably better than Ramkumar's one that says \"if you dropped\".  The user\n> may not know that he is doing an equivalent of dropping as a side effect\n> of the new base that had accepted the same change, and your message nudges\n> the reader to realize that.\n\nI didn't see this patch on the list- did Jan send it to the list?\nYeah, the wording here is nicer, except you might also want to include\nan explicit note on using \"$cmdline --skip\".\n\n-- Ram\n"},{"id":"142624","messageId":"20100601005139.6d0f87c4@jk.gs","threadId":"23942","inReplyTo":"AANLkTinRafLwhzxUuijdBzfzxLtTb_ua3aM1IxVCCgfa@mail.gmail.com","subject":"Re: [PATCH] git-am: suggest what to do with superfluous patches","fromName":"Jan Krüger","fromEmail":"jk@jk.gs","sentAt":"2010-05-31T22:51:39Z","receivedAt":"2010-05-31T22:51:39Z","isPatch":true,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> I didn't see this patch on the list- did Jan send it to the list?\n> Yeah, the wording here is nicer, except you might also want to include\n> an explicit note on using \"$cmdline --skip\".\n\nYes, I did, but apparently something I changed in my mail setup a while\nago caused the list server to silently drop mails sent to the list. I\nthink I've fixed it now. Sorry for the confusion.\n\n-Jan\n"},{"id":"143085","messageId":"m3bpbo1f3f.fsf@winooski.ccs.neu.edu","threadId":"23942","inReplyTo":"4C01B855.7080409@gmail.com","subject":"Re: rebase --continue confusion","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-06-06T13:10:44Z","receivedAt":"2010-06-06T13:10:44Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"Dale Rowley writes:\n>\n> OK, so there isn't a bug in git, but since then I've seen co-workers\n> stumped by this same problem. So maybe it would help to clarify the\n> message? Maybe something like \"The index is in the same state as it\n> was before the patch was applied - refusing to make an empty\n> commit. Did you forget to use 'git add'? Or maybe you should use\n> 'git rebase --skip'?\"\n\nThere are a number of these things that I asked about recently.\nHere's another similarly one:\n\n $ git add foo\n $ git status -s\n M foo\n $ git commit --amend foo\n # On branch master\n # No changes\n $ git status -s\n M foo\n\n-- \n ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"143118","messageId":"20100606221853.GG6993@coredump.intra.peff.net","threadId":"23942","inReplyTo":"m3bpbo1f3f.fsf@winooski.ccs.neu.edu","subject":"Re: rebase --continue confusion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-06-06T22:18:53Z","receivedAt":"2010-06-06T22:18:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 06, 2010 at 09:10:44AM -0400, Eli Barzilay wrote:\n\n> There are a number of these things that I asked about recently.\n> Here's another similarly one:\n> \n> $ git add foo\n> $ git status -s\n> M foo\n> $ git commit --amend foo\n> # On branch master\n> # No changes\n> $ git status -s\n> M foo\n\nI'm confused. Is there some context for when you are issuing these\ncommands? Because the \"git commit --amend foo\" should actually commit\nfoo, and does for me.\n\n-Peff\n"},{"id":"143123","messageId":"19468.8730.59682.76355@winooski.ccs.neu.edu","threadId":"23942","inReplyTo":"20100606221853.GG6993@coredump.intra.peff.net","subject":"Re: rebase --continue confusion","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-06-06T22:32:58Z","receivedAt":"2010-06-06T22:32:58Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Jun 6, Jeff King wrote:\n> On Sun, Jun 06, 2010 at 09:10:44AM -0400, Eli Barzilay wrote:\n> \n> > There are a number of these things that I asked about recently.\n> > Here's another similarly one:\n> > \n> > $ git add foo\n> > $ git status -s\n> > M foo\n> > $ git commit --amend foo\n> > # On branch master\n> > # No changes\n> > $ git status -s\n> > M foo\n> \n> I'm confused. Is there some context for when you are issuing these\n> commands? Because the \"git commit --amend foo\" should actually\n> commit foo, and does for me.\n\nHeh, in that case it was more effective than I thought... My point in\nthe previous posts was also about missing information (in that case,\nmake `git add' tell you when adding it canceled previously added\nchanges, and also make `git status' tell you if you're in the middle\nof a merge or rebase and in a clean state).\n\nIn any case, here's the prelude to the above:\n\n $ mkdir t; cd t; git init\n $ echo foo > foo; git add foo; git commit -m foo\n $ echo bar > foo; git commit -o foo -m bar\n $ echo foo > foo\n\n(And as cooked as it seems, I posted it because I actually ran into it\nthis morning.)\n\n-- \n ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"143125","messageId":"20100606224601.GB11424@coredump.intra.peff.net","threadId":"23942","inReplyTo":"19468.8730.59682.76355@winooski.ccs.neu.edu","subject":"Re: rebase --continue confusion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-06-06T22:46:01Z","receivedAt":"2010-06-06T22:46:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 06, 2010 at 06:32:58PM -0400, Eli Barzilay wrote:\n\n> > > $ git add foo\n> > > $ git status -s\n> > > M foo\n> > > $ git commit --amend foo\n> > > # On branch master\n> > > # No changes\n> > > $ git status -s\n> > > M foo\n> > \n> > I'm confused. Is there some context for when you are issuing these\n> > commands? Because the \"git commit --amend foo\" should actually\n> > commit foo, and does for me.\n> \n> Heh, in that case it was more effective than I thought... My point in\n> the previous posts was also about missing information (in that case,\n> make `git add' tell you when adding it canceled previously added\n> changes, and also make `git status' tell you if you're in the middle\n> of a merge or rebase and in a clean state).\n> \n> In any case, here's the prelude to the above:\n> \n> $ mkdir t; cd t; git init\n> $ echo foo > foo; git add foo; git commit -m foo\n> $ echo bar > foo; git commit -o foo -m bar\n> $ echo foo > foo\n\nAh, I see. Your problem has nothing to do with explicit pathnames (which\nI thought was the interesting bit from your snippet), but rather that\nyou are amending it to the same as HEAD^.\n\nProbably it would be helpful in the case of an amend to indicate what\nhas happened (you have no changes, but it is not immediately obvious\nthat you have no changes against HEAD^, not HEAD). We could even\nsuggest \"git reset HEAD^\", which is probably what you want (the only\nother thing you could want is to create a commit with no changes, which\nwe generally try to avoid).\n\n-Peff\n"},{"id":"143127","messageId":"19468.12912.509183.102990@winooski.ccs.neu.edu","threadId":"23942","inReplyTo":"20100606224601.GB11424@coredump.intra.peff.net","subject":"Re: rebase --continue confusion","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-06-06T23:42:40Z","receivedAt":"2010-06-06T23:42:40Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Jun 6, Jeff King wrote:\n> On Sun, Jun 06, 2010 at 06:32:58PM -0400, Eli Barzilay wrote:\n> \n> > > > $ git add foo\n> > > > $ git status -s\n> > > > M foo\n> > > > $ git commit --amend foo\n> > > > # On branch master\n> > > > # No changes\n> > > > $ git status -s\n> > > > M foo\n> > > \n> > > I'm confused. Is there some context for when you are issuing these\n> > > commands? Because the \"git commit --amend foo\" should actually\n> > > commit foo, and does for me.\n> > \n> > Heh, in that case it was more effective than I thought... My point in\n> > the previous posts was also about missing information (in that case,\n> > make `git add' tell you when adding it canceled previously added\n> > changes, and also make `git status' tell you if you're in the middle\n> > of a merge or rebase and in a clean state).\n> > \n> > In any case, here's the prelude to the above:\n> > \n> > $ mkdir t; cd t; git init\n> > $ echo foo > foo; git add foo; git commit -m foo\n> > $ echo bar > foo; git commit -o foo -m bar\n> > $ echo foo > foo\n> \n> Ah, I see. Your problem has nothing to do with explicit pathnames (which\n> I thought was the interesting bit from your snippet), but rather that\n> you are amending it to the same as HEAD^.\n\nYes.\n\n\n> Probably it would be helpful in the case of an amend to indicate\n> what has happened (you have no changes, but it is not immediately\n> obvious that you have no changes against HEAD^, not HEAD). We could\n> even suggest \"git reset HEAD^\", which is probably what you want (the\n> only other thing you could want is to create a commit with no\n> changes, which we generally try to avoid).\n\nYes, that sounds reasonable. (When I realized what happened I\nwondered why it didn't do the reset itself, but that would obviously\nbe a bad idea.)\n\n-- \n ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"143129","messageId":"20100607004146.GA25106@coredump.intra.peff.net","threadId":"23942","inReplyTo":"19468.12912.509183.102990@winooski.ccs.neu.edu","subject":"Re: rebase --continue confusion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-06-07T00:41:46Z","receivedAt":"2010-06-07T00:41:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 06, 2010 at 07:42:40PM -0400, Eli Barzilay wrote:\n\n> > Probably it would be helpful in the case of an amend to indicate\n> > what has happened (you have no changes, but it is not immediately\n> > obvious that you have no changes against HEAD^, not HEAD). We could\n> > even suggest \"git reset HEAD^\", which is probably what you want (the\n> > only other thing you could want is to create a commit with no\n> > changes, which we generally try to avoid).\n> \n> Yes, that sounds reasonable. (When I realized what happened I\n> wondered why it didn't do the reset itself, but that would obviously\n> be a bad idea.)\n\nI'm not convinced this comes up often enough to really be worth worrying\nabout, but the patch is quite trivial, so why not?\n\n-- >8 --\nSubject: [PATCH] commit: give advice on empty amend\n\nWe generally disallow empty commits with \"git commit\". The\noutput produced by the wt_status functions is generally\nsufficient to explain what happened.\n\nWith --amend commits, however, things are a little more\nconfusing. We would create an empty commit not if you\nactually have staged changes _now_, but if your staged\nchanges match HEAD^. In this case, it is not immediately\nobvious why \"git commit\" claims no changes, but \"git status\"\ndoes not. Furthermore, we should point the user in the\ndirection of git reset, which would eliminate the empty\ncommit entirely.\n\nSigned-off-by: Jeff King \n---\n builtin/commit.c | 7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex 4b2a468..10b09b9 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -48,6 +48,11 @@ static const char implicit_ident_advice[] =\n \"\\n\"\n \" git commit --amend --author='Your Name '\\n\";\n \n+static const char empty_amend_advice[] =\n+\"You asked to amend the most recent commit, but doing so would make\\n\"\n+\"it empty. You can repeat your command with --allow-empty, or you can\\n\"\n+\"remove the commit entirely with \\\"git reset HEAD^\\\".\\n\";\n+\n static unsigned char head_sha1[20];\n \n static char *use_message_buffer;\n@@ -706,6 +711,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix,\n \tif (!commitable && !in_merge && !allow_empty &&\n \t !(amend && is_a_merge(head_sha1))) {\n \t\trun_status(stdout, index_file, prefix, 0, s);\n+\t\tif (amend)\n+\t\t\tfputs(empty_amend_advice, stderr);\n \t\treturn 0;\n \t}\n \n-- \n1.7.1.458.g792cd.dirty\n"}]}