{"thread":{"id":"12966","subject":"[REQ] Better error reporting when git rebase cannot rebase","startedAt":"2008-04-02T15:44:10Z","lastAt":"2008-04-03T13:38:35Z","messageCount":3,"participants":["Jake Goulding","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"73549","messageId":"47F3A9CA.9090307@vivisimo.com","threadId":"12966","inReplyTo":null,"subject":"[REQ] Better error reporting when git rebase cannot rebase","fromName":"Jake Goulding","fromEmail":"goulding@vivisimo.com","sentAt":"2008-04-02T15:44:10Z","receivedAt":"2008-04-02T15:44:10Z","isPatch":false,"sender":{"key":"goulding@vivisimo.com","avatar":"https://gravatar.com/avatar/d8938ff226c618b80857e27f7e0a2d4335215bfb9733c321b8dd30c660b7f1e9?d=mp&s=160"},"body":"Right now, if you have modified files in the working directory and \nattempt to do a git rebase, you will see messages like:\n\n$ git rebase origin/master\nMakefile: needs update\n\nHowever, it isn't always clear that that means the rebase *did not \nwork*. This has bitten a few of my developers a few times when they \nthink that a rebase worked and that they need to perform some sort of \n\"update\" to the files in question.\n\nI would suggest making this more explicit:\n\n$ git rebase origin/master\n* error: rebasing branch master on branch origin/master failed\nMakefile: uncommitted changes would be overwritten\n\nThanks!\n\n-Jake\n"},{"id":"73590","messageId":"20080403095722.GA6673@coredump.intra.peff.net","threadId":"12966","inReplyTo":"47F3A9CA.9090307@vivisimo.com","subject":"Re: [REQ] Better error reporting when git rebase cannot rebase","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-03T09:57:22Z","receivedAt":"2008-04-03T09:57:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 02, 2008 at 11:44:10AM -0400, Jake Goulding wrote:\n\n> Right now, if you have modified files in the working directory and  \n> attempt to do a git rebase, you will see messages like:\n>\n> $ git rebase origin/master\n> Makefile: needs update\n\nI agree that message is terrible. I have long since lost my git\nvirginity, and it makes sense to me now, but I remember getting confused\nby it quite a bit early on.\n\nUnfortunately I am not sure of the best way to fix this message. It\nhappens at a very low level in read-cache.c, and so it shows up in\nseveral different places. I am not even sure of all the places you can\nsee it, so coming up with different text that makes more sense is\nnon-trivial.\n\n> However, it isn't always clear that that means the rebase *did not work*.\n> This has bitten a few of my developers a few times when they think that a \n> rebase worked and that they need to perform some sort of \"update\" to the \n> files in question.\n\nBut this is, I think, a slightly separate issue, which is that rebase\njust bails without saying why. And that's easy to fix. How about this?\n\n-- >8 --\nrebase: warn about uncommitted changes before bailing\n\nIf refreshing the index reports modified files, we used to\njust bail without saying anything else, leaving the user\nonly with the cryptic \"foo: needs update\" message. Let's\nalso tell them that we are canceling the rebase.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nThe message is patterned off the one below it. Maybe \"uncommitted\" is\nnot the right word; technically the changes are _unstaged_. And the\nmessage for the index and head differing says the index is \"not up to\ndate\"; perhaps that should say \"uncommitted changes\".\n\n git-rebase.sh |    5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 9b13b83..045b8ac 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -282,7 +282,10 @@ else\n fi\n \n # The tree must be really really clean.\n-git update-index --refresh || exit\n+if ! git update-index --refresh; then\n+\techo >&2 cannot rebase: you have uncommitted changes\n+\texit 1\n+fi\n diff=$(git diff-index --cached --name-status -r HEAD --)\n case \"$diff\" in\n ?*)\techo \"cannot rebase: your index is not up-to-date\"\n-- \n1.5.5.rc2.170.g6aa60.dirty\n"},{"id":"73599","messageId":"47F4DDDB.60706@vivisimo.com","threadId":"12966","inReplyTo":"20080403095722.GA6673@coredump.intra.peff.net","subject":"Re: [REQ] Better error reporting when git rebase cannot rebase","fromName":"Jake Goulding","fromEmail":"goulding@vivisimo.com","sentAt":"2008-04-03T13:38:35Z","receivedAt":"2008-04-03T13:38:35Z","isPatch":false,"sender":{"key":"goulding@vivisimo.com","avatar":"https://gravatar.com/avatar/d8938ff226c618b80857e27f7e0a2d4335215bfb9733c321b8dd30c660b7f1e9?d=mp&s=160"},"body":"Jeff King wrote:\n> \n> Unfortunately I am not sure of the best way to fix this message. It\n> happens at a very low level in read-cache.c, and so it shows up in\n> several different places. I am not even sure of all the places you can\n> see it, so coming up with different text that makes more sense is\n> non-trivial.\n> \n\nI was afraid that something like that might be the case. Would it be \nworth putting in a second request to make that message more specific?\n\n> But this is, I think, a slightly separate issue, which is that rebase\n> just bails without saying why. And that's easy to fix. How about this?\n> \n > [.snip.]\n\nThat seems good to me. I think the important thing is to make sure that \nthe user is aware that what they wanted to do did not happen.\n"}]}