Sven Verdoolaege [off-list ref] writes:
Recently, rebasing has stopped working for me.
Here is an example:
bash-3.00$ git-show-branch origin HEAD
! [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
! [HEAD] propagate LinearizationType typo fix.
--
+ [HEAD] propagate LinearizationType typo fix.
+ [HEAD^] LinearizationType: typo
+ [HEAD~2] espam::DecomposeChannels: actually decompose the channel if valid.
+ [HEAD~3] DecomposeChannels: split channel and check whether result is a pair of fifos.
+ [HEAD~4] Use proper class for LinearizationType.
+ [HEAD~5] espam/../DecomposeChannels: partial implementation.
+ [HEAD~6] espam: add flag for channel decomposition.
+ [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
++ [HEAD~7] espam/../IndexVector::toString: include contents of IndexVector.
bash-3.00$ git rebase origin
Applying 'espam::DecomposeChannels: actually decompose the channel if valid.'
error: pa/espam/operations/transformations/DecomposeChannels.java: does not exist in index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Trying simple merge.
Simple merge failed, trying Automatic merge.
ERROR: pa/espam/operations/transformations/DecomposeChannels.java: Not handling case 09322db769adbc03bfd4f3ac2720c6d1db5a85b1 -> -> 32da8b1de4205c4adb0da50648a0a00d60b67582
fatal: merge program failed
Failed to merge in the changes.
Patch failed at 0007.
0001-espam-add-flag-for-channel-decomposition.txt
I'm not sure what rebase is doing here, but the only change in origin
modified a file untouched by the changes in HEAD, so there shouldn't
be any conflict whatsoever.
Apparently it's trying to apply the change in HEAD~2 without having
applied the earlier changes (which and the file named above).
What it should be doing (although I have not seen this kind of
breakage myself, there could be a bug that makes rebase not to
do what it should be doing) is:
- save the original HEAD to .git/ORIG_HEAD
- reset the tree to origin without switching branches
- prepare patches for changes ~6, ~5, ... brings in
- feed that to git-am, which saves the 7 patches in
.dotest/0001 through .dotest/0007 and starts applying them.
As the first thing to do after you see something like this,
please stash away ORIG_HEAD, like this:
$ git branch before-rebase-precious ORIG_HEAD
After this, if you choose not to rebase for whatever reason,
including "rebase is broken X-<", you could do
$ git-reset --hard before-rebase-precious
to come back to the state before trying rebase.
The output seems very inconsistent I am not sure why the first
message says "Applying HEAD~2", not HEAD~6. What patches do
you see in .dotest/ directory, and are they numbered in the
right order? HEAD~6 should be numbered 0001 and that should be
the first one that was applied.
On Mon, Nov 28, 2005 at 12:19:40PM -0800, Junio C Hamano wrote:
The output seems very inconsistent I am not sure why the first
message says "Applying HEAD~2", not HEAD~6. What patches do
you see in .dotest/ directory, and are they numbered in the
right order? HEAD~6 should be numbered 0001 and that should be
the first one that was applied.
Ah! It seems .dotest still contained some stuff from a previous
(expectedly) failed rebase.
Rebase worked after rm -rf'ing .dotest
Maybe rebase should clean up .dotest or at least warn about
an existing .dotest ?
Thanks,
skimo
Sven Verdoolaege [off-list ref] writes:
On Mon, Nov 28, 2005 at 12:19:40PM -0800, Junio C Hamano wrote:
quoted
The output seems very inconsistent I am not sure why the first
message says "Applying HEAD~2", not HEAD~6. What patches do
you see in .dotest/ directory, and are they numbered in the
right order? HEAD~6 should be numbered 0001 and that should be
the first one that was applied.
Ah! It seems .dotest still contained some stuff from a previous
(expectedly) failed rebase.
Rebase worked after rm -rf'ing .dotest
Maybe rebase should clean up .dotest or at least warn about
an existing .dotest ?
Thanks, you are right. I was coming to the same conclusion.
There are a few more problems in the current rebase.
- If the branch being rebased is fully in sync with the master
(i.e. there is no patch to apply), it fails with a mysterious
message "fatal: cannot read mbox".
- If the branch being rebased is already a proper descendant of
the master, it still goes ahead and rebases. This is
unnecessary.
I think something like this is necessary.
-- >8 --
[PATCH] rebase: one safety net, one bugfix and one optimization.
When a .dotest from a previously failed rebase or patch
application exists, rebase got confused and tried to apply
mixture of what was already there and what is being rebased.
Check the existence of the directory and barf.
It failed with an mysterious "fatal: cannot read mbox" message
if the branch being rebased is fully in sync with the base.
Also if the branch is a proper descendant of the base, there is
no need to run rebase logic. Prevent these from happening by
checking where the merge-base is.
Signed-off-by: Junio C Hamano <redacted>
---
git-rebase.sh | 28 +++++++++++++++++++++++++++-
1 files changed, 27 insertions(+), 1 deletions(-)
applies-to: fe523a4df93cce3e5c5b0266b9d3f1cbea009afa
7f4bd5d831ea838668d1de5f5af022f763230eee
diff --git a/git-rebase.sh b/git-rebase.sh
index 2bc3a12..638ff0d 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -5,9 +5,25 @@
. git-sh-setup
-# The other head is given
+# Make sure we do not have .dotest
+if mkdir .dotest
+then
+ rmdir .dotest
+else
+ echo >&2 '
+It seems that I cannot create a .dotest directory, and I wonder if you
+are in the middle of patch application or another rebase. If that is not
+the case, please rm -fr .dotest and run me again. I am stopping in case
+you still have something valuable there.'
+ exit 1
+fi
+
+# The other head is given. Make sure it is valid.
other=$(git-rev-parse --verify "$1^0") || exit
+# Make sure we have HEAD that is valid.
+head=$(git-rev-parse --verify "HEAD^0") || exit
+
# The tree must be really really clean.
git-update-index --refresh || exit
diff=$(git-diff-index --cached --name-status -r HEAD)
@@ -23,6 +39,16 @@ case "$#" in
git-checkout "$2" || exit
esac
+# If the HEAD is a proper descendant of $other, we do not even need
+# to rebase. Make sure we do not do needless rebase. In such a
+# case, merge-base should be the same as "$other".
+mb=$(git-merge-base "$other" "$head")
+if test "$mb" = "$other"
+then
+ echo >&2 "Current branch `git-symbolic-ref HEAD` is up to date."
+ exit 0
+fi
+
# Rewind the head to "$other"
git-reset --hard "$other"
git-format-patch -k --stdout --full-index "$other" ORIG_HEAD |
---
0.99.9.GIT