Folks,
I have recently hit a behavior which might well be a feature,
but it was very surprising (in a bad sense) to me.
I was trying to rebase a branch with changes in some file onto a branch
where this file was recently deleted. I would expect rebase to fail and
suggest me to resolve conflict manually.
However it somehow succeeded managing to find another file to patch instead
of the initial one:
] cat git-rebase-bug.sh
#!/bin/sh
git init
# create three files with the same contents
perl -e ' for ($i=0; $i < 10; $i++) { print "$i\n" } ' >Makefile
cp Makefile Makefile1
cp Makefile Makefile2
git add .
git commit -m"created 3 makefiles"
# delete one file
git rm Makefile
git commit -m"deleted 1 makefile"
# go to another branch, one step back
git checkout -b mod HEAD^
# modify contents of the file deleted in master branch
echo "#10" >>Makefile
git add -u
git commit -m"modified 1 makefile"
# now rebase "mod" on top of "master" not expecting it to succeed
git rebase master mod
]
] mkdir git-bug; cd git-bug
] ../git-rebase-bug.sh
....
First, rewinding head to replay your work on top of it...
Applying: modified 1 makefile
error: Makefile: does not exist in index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
]
Now if I look at the rebase result I see that it chose to patch "Makefile2"
instead of my lovely "Makefile" (why not Makefile1, btw ;) ):
] git log --stat -1 --pretty=oneline
ce0101fc7884bce3eb9724b75d654e7c40abf0fd modified 1 makefile
Makefile2 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
]
I has always agreed with the claim that simple but reliable merge
(rebase, whatever) is much better than smartass one smarter than yourself.
And, to be honest, both merge and cherry-pick do not try to play smart:
] git reset --hard mod@{1}
] git checkout master
] git merge mod
CCONFLICT (delete/modify): Makefile deleted in HEAD and modified in mod. Version mod of Makefile left in tree.
Automatic merge failed; fix conflicts and then commit the result.
] git reset --hard
] git cherry-pick mod
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
When commiting, use the option '-c f782a81' to retain authorship and message.
]
So, why rebase is smarter?
Yeah, and if it matters I tried it on 1.6.0.2 and 1.5.3.8 on Solaris and Linux.
best regards,
Fedor.
PS I had problems reaching this list, thus ccing Junio explicitly.
I'm not on the list, btw..
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
