Michael Witten wrote:
> 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
> }
Woops!
This line:
git checkout -- $commit
should be:
git checkout $commit -- .
--
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