Re: Cleaning up history with git rebase
- From
Michael Witten <mfwitten@gmail.com>
- Date
- Aug 1, 2011, 01:02 UTC
- Message-ID
- <7af8ef40e0034e81a63f1d4a53bf082e-mfwitten@gmail.com>
- In-Reply-To
- <317AAE40-449B-4280-AEF1-10EE93FDB9FF@linea.gov.br>
On Sun, 31 Jul 2011 18:44:43 -0300, Ricky, Egeland wrote:
Show 22 quoted lines
> On Jul 31, 2011, at 6:33 PM, Michael Witten wrote: > >> On Sun, Jul 31, 2011 at 20:21, Michael Witten <mfwitten@gmail.com> wrote: >>> Why are there conflicts anyway? >> >> Oh... >> >> I guess there were conflicts when the merge commit was made in >> the original repository, and these conflicts were resolved by >> the merge commit itself. Hence, when rebase tries to split up >> a merge by dealing with just the non-merge parents, you end up >> having to deal with the conflict again. > > Yes, I thought it was something like this going on, too. In the > pre-rebase history, when there is a commit with "Conflict:" and > listing file which is in the sub-repository history, this is a > point where rebase stops with a conflict. > >> Shouldn't rebase take this into account? > > Not sure. Seems that it does not, it makes me resolve the conflict = > again.
I think git rebase should take this into account is what I'm saying.
The following implements what I think `git rebase' should be doing; run it instead of `git rebase' in your repo:
git branch saved
git rev-list HEAD --reverse --first-parent --parents |
{
read root
git reset --hard $root
rebase_head=$rootwhile read commit first_parent other_parents; do
if [ -z "$other_parents" ]; then
git cherry-pick $commit
rebase_head=$commitelse
for parent in $other_parents; do
if ! git cherry-pick $parent; then
git reset --hard $rebase_head
git merge $other_parents
git rm -rf .
git checkout -- $commit
git commit -aC $commit
breakfi
done
rebase_head=$(git rev-parse HEAD)
fi
done }
Sincerely, Michael Witten