rebase --continue confusion

I ran into a conflict while running 'git rebase branch1 branch2'. So I edited
the file and resolved the conflicts, and then ran 'git add <file>; git rebase
--continue'. This printed out a message 'No changes - did you forget to use git
add?'. I thought 'No, I'm pretty sure I ran git add' and I assumed I had run
into a bug in git because I didn't see how this conflict was different than any
others I had successfully resolved. The next time this problem came up, the
light finally came on and I realized that I should just run 'git rebase --skip'
because when I resolved the conflicts, I had basically undone all changes that
the patch would introduce.

OK, so there isn't a bug in git, but since then I've seen co-workers stumped by
this same problem. So maybe it would help to clarify the message? Maybe
something like "The index is in the same state as it was before the patch was
applied - refusing to make an empty commit. Did you forget to use 'git add'? Or
maybe you should use 'git rebase --skip'?"


Dale

On Sat, May 29, 2010 at 8:59 PM, Dale Rowley [off-list ref] wrote:

I ran into a conflict while running 'git rebase branch1 branch2'. So I edited
the file and resolved the conflicts, and then ran 'git add <file>; git rebase
--continue'. This printed out a message 'No changes - did you forget to use git
add?'. I thought 'No, I'm pretty sure I ran git add' and I assumed I had run
into a bug in git because I didn't see how this conflict was different than any
others I had successfully resolved. The next time this problem came up, the
light finally came on and I realized that I should just run 'git rebase --skip'
because when I resolved the conflicts, I had basically undone all changes that
the patch would introduce.

OK, so there isn't a bug in git, but since then I've seen co-workers stumped by
this same problem. So maybe it would help to clarify the message? Maybe
something like "The index is in the same state as it was before the patch was
applied - refusing to make an empty commit. Did you forget to use 'git add'? Or
maybe you should use 'git rebase --skip'?"

2 things.

1. I agree that the message could be more informative, especially
given the context.  If the the patch looks exactly like the last patch
applied now that you've edited it during a rebase, it would _almost_
be safe to assume that you meant to skip and just didn't know you were
going to before hand.

2. `git status` should show you that you had nothing to commit, which
would completely explain why `git rebase --continue` threw out the
message it did.  I'm in the habit of running `git st` continually and
it often helps me catch this sort of thing where I thought I'd added
something to the index or forgot that I'd changed some file between
the last time I'd updated the index or something along those lines.
This is just sort of a recommendation on a way to modify your work
flow that may help you and your coworkers in the future.  YMMV.

-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail

On Sat, May 29, 2010 at 5:59 PM, Dale Rowley [off-list ref] wrote:

I ran into a conflict while running 'git rebase branch1 branch2'. So I edited
the file and resolved the conflicts, and then ran 'git add <file>; git rebase
--continue'. This printed out a message 'No changes - did you forget to use git
add?'. I thought 'No, I'm pretty sure I ran git add' and I assumed I had run
into a bug in git because I didn't see how this conflict was different than any
others I had successfully resolved. The next time this problem came up, the
light finally came on and I realized that I should just run 'git rebase --skip'
because when I resolved the conflicts, I had basically undone all changes that
the patch would introduce.

OK, so there isn't a bug in git, but since then I've seen co-workers stumped by
this same problem. So maybe it would help to clarify the message? Maybe
something like "The index is in the same state as it was before the patch was
applied - refusing to make an empty commit. Did you forget to use 'git add'? Or
maybe you should use 'git rebase --skip'?"

I agree. I actually wasn't as smart as you when I saw that message in
the past. I didn't know what the problem was and I didn't know about
git rebase --skip (or I probably ignored it when I tried git rebase -h
since skipping didn't sound like what I wanted at the time, but thanks
for pointing it out if run into this in the future). I think I'd like
git to just skip automatically in this case.

Dale Rowley [off-list ref] writes:

OK, so there isn't a bug in git, but since then I've seen co-workers
stumped by this same problem. So maybe it would help to clarify the
message? Maybe something like "The index is in the same state as it
was before the patch was applied - refusing to make an empty
commit. Did you forget to use 'git add'? Or maybe you should use
'git rebase --skip'?"

There are a number of these things that I asked about recently.
Here's another similarly one:

  $ git add foo
  $ git status -s
  M  foo
  $ git commit --amend foo
  # On branch master
  # No changes
  $ git status -s
  M  foo

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

On Sun, Jun 06, 2010 at 09:10:44AM -0400, Eli Barzilay wrote:

There are a number of these things that I asked about recently.
Here's another similarly one:

  $ git add foo
  $ git status -s
  M  foo
  $ git commit --amend foo
  # On branch master
  # No changes
  $ git status -s
  M  foo

I'm confused. Is there some context for when you are issuing these
commands? Because the "git commit --amend foo" should actually commit
foo, and does for me.

-Peff

On Jun  6, Jeff King wrote:

On Sun, Jun 06, 2010 at 09:10:44AM -0400, Eli Barzilay wrote:

quoted

There are a number of these things that I asked about recently.
Here's another similarly one:

  $ git add foo
  $ git status -s
  M  foo
  $ git commit --amend foo
  # On branch master
  # No changes
  $ git status -s
  M  foo

I'm confused. Is there some context for when you are issuing these
commands?  Because the "git commit --amend foo" should actually
commit foo, and does for me.

Heh, in that case it was more effective than I thought...  My point in
the previous posts was also about missing information (in that case,
make `git add' tell you when adding it canceled previously added
changes, and also make `git status' tell you if you're in the middle
of a merge or rebase and in a clean state).

In any case, here's the prelude to the above:

  $ mkdir t; cd t; git init
  $ echo foo > foo; git add foo; git commit -m foo
  $ echo bar > foo; git commit -o foo -m bar
  $ echo foo > foo

(And as cooked as it seems, I posted it because I actually ran into it
this morning.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

On Sun, Jun 06, 2010 at 06:32:58PM -0400, Eli Barzilay wrote:

quoted

quoted

  $ git add foo
  $ git status -s
  M  foo
  $ git commit --amend foo
  # On branch master
  # No changes
  $ git status -s
  M  foo

I'm confused. Is there some context for when you are issuing these
commands?  Because the "git commit --amend foo" should actually
commit foo, and does for me.

Heh, in that case it was more effective than I thought...  My point in
the previous posts was also about missing information (in that case,
make `git add' tell you when adding it canceled previously added
changes, and also make `git status' tell you if you're in the middle
of a merge or rebase and in a clean state).

In any case, here's the prelude to the above:

  $ mkdir t; cd t; git init
  $ echo foo > foo; git add foo; git commit -m foo
  $ echo bar > foo; git commit -o foo -m bar
  $ echo foo > foo

Ah, I see. Your problem has nothing to do with explicit pathnames (which
I thought was the interesting bit from your snippet), but rather that
you are amending it to the same as HEAD^.

Probably it would be helpful in the case of an amend to indicate what
has happened (you have no changes, but it is not immediately obvious
that you have no changes against HEAD^, not HEAD). We could even
suggest "git reset HEAD^", which is probably what you want (the only
other thing you could want is to create a commit with no changes, which
we generally try to avoid).

-Peff

On Jun  6, Jeff King wrote:

On Sun, Jun 06, 2010 at 06:32:58PM -0400, Eli Barzilay wrote:

quoted

quoted

quoted

  $ git add foo
  $ git status -s
  M  foo
  $ git commit --amend foo
  # On branch master
  # No changes
  $ git status -s
  M  foo

I'm confused. Is there some context for when you are issuing these
commands?  Because the "git commit --amend foo" should actually
commit foo, and does for me.

Heh, in that case it was more effective than I thought...  My point in
the previous posts was also about missing information (in that case,
make `git add' tell you when adding it canceled previously added
changes, and also make `git status' tell you if you're in the middle
of a merge or rebase and in a clean state).

In any case, here's the prelude to the above:

  $ mkdir t; cd t; git init
  $ echo foo > foo; git add foo; git commit -m foo
  $ echo bar > foo; git commit -o foo -m bar
  $ echo foo > foo

Ah, I see. Your problem has nothing to do with explicit pathnames (which
I thought was the interesting bit from your snippet), but rather that
you are amending it to the same as HEAD^.

Yes.

Probably it would be helpful in the case of an amend to indicate
what has happened (you have no changes, but it is not immediately
obvious that you have no changes against HEAD^, not HEAD). We could
even suggest "git reset HEAD^", which is probably what you want (the
only other thing you could want is to create a commit with no
changes, which we generally try to avoid).

Yes, that sounds reasonable.  (When I realized what happened I
wondered why it didn't do the reset itself, but that would obviously
be a bad idea.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

On Sun, Jun 06, 2010 at 07:42:40PM -0400, Eli Barzilay wrote:

quoted

Probably it would be helpful in the case of an amend to indicate
what has happened (you have no changes, but it is not immediately
obvious that you have no changes against HEAD^, not HEAD). We could
even suggest "git reset HEAD^", which is probably what you want (the
only other thing you could want is to create a commit with no
changes, which we generally try to avoid).

Yes, that sounds reasonable.  (When I realized what happened I
wondered why it didn't do the reset itself, but that would obviously
be a bad idea.)

I'm not convinced this comes up often enough to really be worth worrying
about, but the patch is quite trivial, so why not?

-- >8 --
Subject: [PATCH] commit: give advice on empty amend

We generally disallow empty commits with "git commit". The
output produced by the wt_status functions is generally
sufficient to explain what happened.

With --amend commits, however, things are a little more
confusing. We would create an empty commit not if you
actually have staged changes _now_, but if your staged
changes match HEAD^. In this case, it is not immediately
obvious why "git commit" claims no changes, but "git status"
does not. Furthermore, we should point the user in the
direction of git reset, which would eliminate the empty
commit entirely.

Signed-off-by: Jeff King <redacted>
---
 builtin/commit.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 4b2a468..10b09b9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c

@@ -48,6 +48,11 @@ static const char implicit_ident_advice[] =
 "\n"
 "    git commit --amend --author='Your Name <you@example.com>'\n";
 
+static const char empty_amend_advice[] =
+"You asked to amend the most recent commit, but doing so would make\n"
+"it empty. You can repeat your command with --allow-empty, or you can\n"
+"remove the commit entirely with \"git reset HEAD^\".\n";
+
 static unsigned char head_sha1[20];
 
 static char *use_message_buffer;

@@ -706,6 +711,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 	if (!commitable && !in_merge && !allow_empty &&
 	    !(amend && is_a_merge(head_sha1))) {
 		run_status(stdout, index_file, prefix, 0, s);
+		if (amend)
+			fputs(empty_amend_advice, stderr);
 		return 0;
 	}
 

-- 
1.7.1.458.g792cd.dirty