Re: Cleaning up history with git rebase

> 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
>   }