Ah, but you don't understand. Git branches are not *meant* to be straight.
They are meant to be crooky!
2017-05-03 20:56 GMT+02:00 Michael <keybou...@gmail.com>:
>
> 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.
>
--
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.
