Re: Cleaning up history with git rebase

[Michael Witten <mfwitten@gmail.com>]

On Sun, 31 Jul 2011 18:44:43 -0300, Ricky, Egeland wrote:

> 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=$root

    while read commit first_parent other_parents; do

      if [ -z "$other_parents" ]; then

        git cherry-pick $commit
        rebase_head=$commit

      else

        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 
            break

          fi

        done

        rebase_head=$(git rev-parse HEAD)

      fi

    done
  }

Sincerely,
Michael Witten