This sounds like you need "iMerge". Incremental merge -- basically, every 
small, tiny diff is made, so that all conflicts are tiny.

Doesn't mean that they all are easy. If you've ever had one change made in 
multiple small commits, then things can still be difficult.

On 2017-04-30, at 6:47 AM, m...@jump-ing.de wrote:

> 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 git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

---
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.

Reply via email to