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@xxxxxxxxx> 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
--
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