Git repo with some 40'000 commits here and two main branches, which parted
long ago. Plan is to bring these branches back together to find out what
was changed since then. Diff is 793'487 lines, so just looking at that
isn't really an option. Instead, the strategy is to rebase the newer branch
onto the older one, then looking at the commits. Looking at the commits
should give some hints on what belongs together and also allows to drop the
unneeded parts without too much manual file editing.
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.
Sounds straightforwoard, doesn't it?
git checkout newwork
git rebase oldwork~1300
git rebase oldwork~1250
... and so on.
Rebasing not all at once to keep conflicts manageable.
Too bad, this doesn't work. Conflicts in about every single commit, despite
rebasing by just 8 commits on the other branch. Most conflicts, if not all,
are entirely unrelated to changes in these 8 commits. Apparently, there's
something wrong.
Next strategy. Try rebasing the branch to its self to curtail the zone of
fault. Like
git checkout newwork
git rebase newwork~1904
This should just give a 'current branch is up to date', right? Well, no, it
doesn't.
Third strategy. Do the same in small chunks. Like:
git checkout newwork
git rebase newwork~10
git rebase newwork~20
...
Works better. However, there are still conflicts. HUH? Conflicts by just
rebuilding an existing branch as-is? Doesn't match my understanding of how
Git works.
As a side note: the common anchestor moved during these step-wise
self-rebases. It used to be newwork~1904, after self-rebasing to ~1900 it
had moved to newwork~2839.
Further investigation brought up that these conflicts happen at merge
points in the history. Even merges recorded as being merged without
conflict can cause hundreds of conflicts when being rebased, most of these
conflicts being totally unrelated to what was merged. One of these
incidents caused conflicts in almost every commit and figuring how long it
whould take me to resolve some 2000 conflicts manually made me giving up.
All this makes me think that the essential
*question is: How does one get a complex branch into a plain series of
commits, without merges in the history, without changing code on the branch
tip and of course without manual conflict resolution?*
Proof for success: 'git rebase newwork~2500' whould just report 'Current
branch is up to date' and a diff to a copy of the complex branch whould
come up empty.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
