All of lore.kernel.org
 help / color / mirror / Atom feed
* [REQ] Better error reporting when git rebase cannot rebase
@ 2008-04-02 15:44 Jake Goulding
  2008-04-03  9:57 ` Jeff King
  0 siblings, 1 reply; 3+ messages in thread
From: Jake Goulding @ 2008-04-02 15:44 UTC (permalink / raw)
  To: git

Right now, if you have modified files in the working directory and 
attempt to do a git rebase, you will see messages like:

$ git rebase origin/master
Makefile: needs update

However, it isn't always clear that that means the rebase *did not 
work*. This has bitten a few of my developers a few times when they 
think that a rebase worked and that they need to perform some sort of 
"update" to the files in question.

I would suggest making this more explicit:

$ git rebase origin/master
* error: rebasing branch master on branch origin/master failed
Makefile: uncommitted changes would be overwritten

Thanks!

-Jake

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [REQ] Better error reporting when git rebase cannot rebase
  2008-04-02 15:44 [REQ] Better error reporting when git rebase cannot rebase Jake Goulding
@ 2008-04-03  9:57 ` Jeff King
  2008-04-03 13:38   ` Jake Goulding
  0 siblings, 1 reply; 3+ messages in thread
From: Jeff King @ 2008-04-03  9:57 UTC (permalink / raw)
  To: Jake Goulding; +Cc: Junio C Hamano, git

On Wed, Apr 02, 2008 at 11:44:10AM -0400, Jake Goulding wrote:

> Right now, if you have modified files in the working directory and  
> attempt to do a git rebase, you will see messages like:
>
> $ git rebase origin/master
> Makefile: needs update

I agree that message is terrible. I have long since lost my git
virginity, and it makes sense to me now, but I remember getting confused
by it quite a bit early on.

Unfortunately I am not sure of the best way to fix this message. It
happens at a very low level in read-cache.c, and so it shows up in
several different places. I am not even sure of all the places you can
see it, so coming up with different text that makes more sense is
non-trivial.

> However, it isn't always clear that that means the rebase *did not work*.
> This has bitten a few of my developers a few times when they think that a 
> rebase worked and that they need to perform some sort of "update" to the 
> files in question.

But this is, I think, a slightly separate issue, which is that rebase
just bails without saying why. And that's easy to fix. How about this?

-- >8 --
rebase: warn about uncommitted changes before bailing

If refreshing the index reports modified files, we used to
just bail without saying anything else, leaving the user
only with the cryptic "foo: needs update" message. Let's
also tell them that we are canceling the rebase.

Signed-off-by: Jeff King <peff@peff.net>
---
The message is patterned off the one below it. Maybe "uncommitted" is
not the right word; technically the changes are _unstaged_. And the
message for the index and head differing says the index is "not up to
date"; perhaps that should say "uncommitted changes".

 git-rebase.sh |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 9b13b83..045b8ac 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -282,7 +282,10 @@ else
 fi
 
 # The tree must be really really clean.
-git update-index --refresh || exit
+if ! git update-index --refresh; then
+	echo >&2 cannot rebase: you have uncommitted changes
+	exit 1
+fi
 diff=$(git diff-index --cached --name-status -r HEAD --)
 case "$diff" in
 ?*)	echo "cannot rebase: your index is not up-to-date"
-- 
1.5.5.rc2.170.g6aa60.dirty

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [REQ] Better error reporting when git rebase cannot rebase
  2008-04-03  9:57 ` Jeff King
@ 2008-04-03 13:38   ` Jake Goulding
  0 siblings, 0 replies; 3+ messages in thread
From: Jake Goulding @ 2008-04-03 13:38 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, git

Jeff King wrote:
> 
> Unfortunately I am not sure of the best way to fix this message. It
> happens at a very low level in read-cache.c, and so it shows up in
> several different places. I am not even sure of all the places you can
> see it, so coming up with different text that makes more sense is
> non-trivial.
> 

I was afraid that something like that might be the case. Would it be 
worth putting in a second request to make that message more specific?

> But this is, I think, a slightly separate issue, which is that rebase
> just bails without saying why. And that's easy to fix. How about this?
> 
 > [.snip.]

That seems good to me. I think the important thing is to make sure that 
the user is aware that what they wanted to do did not happen.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-04-03 13:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-02 15:44 [REQ] Better error reporting when git rebase cannot rebase Jake Goulding
2008-04-03  9:57 ` Jeff King
2008-04-03 13:38   ` Jake Goulding

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.