On 2017-05-02, at 10:30 AM, Michael <keybou...@gmail.com> wrote:
>
> On 2017-05-02, at 10:22 AM, m...@jump-ing.de wrote:
>
>>
>> As nobody knew an answer, so I started trying rebase strategies (-s, -X
>> options), one by one. Using 'git rebase -s recursive -X ours ...' was the
>> only one which did something useful for this self-rebase and also worked
>> with a mangeable set of conflicts (only ones including a file deletion), so
>> I got away with resolving some 30 conflicts with 'git rm ...'. Now I have a
>> branch with 4700 commits on it, but zero merges. Diff melted down to 3800
>> lines. That's something I can work with.
>>
>> Go home message: merges are evil!
>
> Merges should not be evil. Something really odd was going on here.
>
> A better take-home message should be about how to prevent this from happening
> in the future.
>
> What I don't understand, exactly, is "a branch with 4700 commits but zero
> merges". I thought that merging was the goal here?
Ok, so I went back and re-read your original. Your goal, basically, was to do a
rebase.
I'm not familiar enough with rebase to know what was going on with your initial
commands, but the idea of "I want to rebase this part of this branch on itself"
doesn't seem like it would make sense.
When you say,
> With some patience I managed to find the common anchestor ('git merge-base'
> wasn't accurate on that), which happens to be oldwork~1308 and newwork~1904.
> Both of them highly complex, more than thousand merges in each.
My understanding of the ~ notation is that it means "go back that many commits"
-- which means as you add more things, you change the destination. You should
be looking at the commit hash / aka the "sha1" of that commit, and it had
better be the same on both branches (i.e. -- the common ancestor of oldworld
and newwork should be the same commit with the same sha1.)
iMerge is basically a two-part tool. Part one does a massive tiny piece by tiny
piece merge, that makes each little merge small and manageable, and generates a
messively intertwined history; part 2 re-writes that history. One of the
"re-write" options makes the result look like a normal rebase.
I don't know if this would have been a better option. It sounds like you got a
"fast, approximate" result, that you can now go over to try to manually fix.
iMerge probably would take a little longer, with perhaps less manual cleanup
afterwards.
---
Entertaining minecraft videos
http://YouTube.com/keybounce
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
