If git rebase interactive is stopped by "edit" command and then the user
said "git rebase --continue" while having some stage changes, git rebase
interactive is trying to amend the last commit by doing:
git --soft reset && git commit
However, the user can abort commit for some reason by providing an empty
log message, and that would leave the last commit undone, while the user
being completely unaware about what happened. Now if the user tries to
continue, by issuing "git rebase --continue" that squashes two previous
commits.
Signed-off-by: Dmitry Potapov <redacted>
---
git-rebase--interactive.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 929d681..5b2b1e5 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -429,12 +429,15 @@ do
die "Cannot find the author identity"
if test -f "$DOTEST"/amend
then
+ amend=$(git rev-parse --verify HEAD)
git reset --soft HEAD^ ||
die "Cannot rewind the HEAD"
fi
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
- git commit --no-verify -F "$DOTEST"/message -e ||
- die "Could not commit staged changes."
+ git commit --no-verify -F "$DOTEST"/message -e || {
+ test -n "$amend" && git reset --soft $amend
+ die "Could not commit staged changes."
+ }
fi
require_clean_work_tree--
1.6.0
"git rebase --continue" issued after git rebase being stop by "edit"
command is trying to amend the last commit using stage changes. However,
if the last commit is not the commit that was marked as "edit" then it
can produce unexpected results.
For instance, after being stop by "edit", I have made some changes to
commit message using "git commit --amend". After that I realized that
I forgot to add some changes to some file. So, I said "git add file"
and the "git rebase --continue". Unfortunately, it caused that the new
commit message was lost.
Another problem is that after being stopped at "edit", the user adds new
commits. In this case, automatic amend behavior of git rebase triggered
by some stage changes causes that not only that the log message of the
last commit is lost but that it will contain also wrong Author and Date
information.
Therefore, this patch restrict automatic amend only to the situation
where HEAD is the commit at which git rebase stop by "edit" command.
Signed-off-by: Dmitry Potapov <redacted>
---
git-rebase--interactive.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 5b2b1e5..84721c9 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -284,7 +284,7 @@ do_next () {
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
make_patch $sha1
- : > "$DOTEST"/amend
+ echo $sha1 > "$DOTEST"/amend
warn "Stopped at $sha1... $rest"
warn "You can amend the commit now, with"
warn@@ -430,6 +430,8 @@ do
if test -f "$DOTEST"/amend
then
amend=$(git rev-parse --verify HEAD)
+ test "$amend" = $(cat "$DOTEST"/amend) ||
+ die "You have uncommitted changes"
git reset --soft HEAD^ ||
die "Cannot rewind the HEAD"
fi
--
1.6.0
Dmitry Potapov schrieb:
Another problem is that after being stopped at "edit", the user adds new
commits. In this case, automatic amend behavior of git rebase triggered
by some stage changes causes that not only that the log message of the
last commit is lost but that it will contain also wrong Author and Date
information.
Therefore, this patch restrict automatic amend only to the situation
where HEAD is the commit at which git rebase stop by "edit" command.
...
quoted hunk
@@ -430,6 +430,8 @@ do
if test -f "$DOTEST"/amend
then
amend=$(git rev-parse --verify HEAD)
+ test "$amend" = $(cat "$DOTEST"/amend) ||
+ die "You have uncommitted changes"
Doesn't this terse message carry a bit of a "WTF?" factor? In other
situations rebase --continue goes into git-commit just fine, but it does
not under these special conditions. How about this:
"Will not auto-commit uncommitted changes after you have already committed
something. Please run 'git commit --amend' yourself."
git reset --soft HEAD^ ||
die "Cannot rewind the HEAD"
fi
-- Hannes
On Tue, Sep 09, 2008 at 08:42:57AM +0200, Johannes Sixt wrote:
Dmitry Potapov schrieb:
quoted
Another problem is that after being stopped at "edit", the user adds new
commits. In this case, automatic amend behavior of git rebase triggered
by some stage changes causes that not only that the log message of the
last commit is lost but that it will contain also wrong Author and Date
information.
Therefore, this patch restrict automatic amend only to the situation
where HEAD is the commit at which git rebase stop by "edit" command.
...
quoted
@@ -430,6 +430,8 @@ do
if test -f "$DOTEST"/amend
then
amend=$(git rev-parse --verify HEAD)
+ test "$amend" = $(cat "$DOTEST"/amend) ||
+ die "You have uncommitted changes"
Doesn't this terse message carry a bit of a "WTF?" factor?
Agreed. However, the current message in the case when you have some
unstaged changes in your working tree is not much better:
"Working tree is dirty"
In other
situations rebase --continue goes into git-commit just fine, but it does
not under these special conditions. How about this:
"Will not auto-commit uncommitted changes after you have already committed
something. Please run 'git commit --amend' yourself."
I don't think this is the right suggestion. In cases that I mentioned above
(and in some others), you may want to run 'git commit' *without* --amend.
Only user may know how those changes should be committed. Giving him/her
a direct instruction to run some specific command will produce the wrong
result in half cases. So, how about this:
"You have uncommitted changes in your working tree. Please, commit them
first and then run 'git rebase --continue' again."
or if you want to describe the cause why auto-commit does not work:
"Will not auto-commit uncommitted changes after you have already committed
something. Please commit them first and then run 'git rebase --continue'
again."
Personally, I believe those words about auto-commit is not very helpful.
Auto-commit-on-edit feature is undocumented. So, those words may be more
confusing than helpful, because the user starts thinking what this auto-
commit means, while the real question here is whether changes should be
committed with --amend or without it.
Dmitry