[_fbpt]

About half a year ago, I tried to merge two forks of a single program which had diverged by several years. I tried a Git merge, got halfway through conflict resolution, stashed my current changes and reset my repository, and could not reapply my partial resolution. (The proper approach would've been to manually run `git rerere` without arguments to save the current partial resolution, but I didn't know that).

I redid the merge in Pijul. Pijul had a bug causing it to misread the filesystem's execute bit, and no amount of `pijul reset` would fix it. Pijul's merge conflict textual syntax was baffling as well. I think it was a stack which was pushed and popped by >>> and <<< markers, and anything under === was something I should probably remove. In the end, I did succeed in the merge, but reconciling the two projects didn't work out.

(FamiTracker was based off the MFC GUI library. It was forked to 0CC-FamiTracker, and another fork ported it to a MFC compatibility layer with a cross-platform Qt backend. The MFC compatibility layer didn't support all the functionality used by 0CC-FamiTracker.)

[lillecarl]

I suggest you check out git-imerge, it's a quite handy tool for making complex/big merges simple.

[_fbpt]

https://github.com/mhagger/git-imerge

> Reduce the pain of resolving merge conflicts to its unavoidable minimum, by finding and presenting the smallest possible conflicts: those between the changes introduced by one commit from each branch.

I'm not sure this would've helped in my scenario. famitracker had no public repo, and the Qt fork and 0cc-famitracker came from different Git repositories and were rooted in different subdirectories. I created a synthetic Git and Pijul history for the purpose of this merge.

But it might be helpful in other situations. I'll look into it.

> Allow a merge to be saved, tested, interrupted, published, and collaborated on while it is in progress.

This does seem useful.