[cfe-dev] Maintaining a clang fork

[David Chisnall via cfe-dev]

You’ve had lots of other replies, but no one has yet mentioned git-imerge.  It burns a *lot* of cycles, but I’ve found that it’s the best way of handling the merges.  It identifies the pair of revisions (yours and upstream) that cause a conflict and lets you fix them one at a time.

Unfortunately, the clang and llvm git repos are separate in the git export, so you can’t easily run the clang test suite during the merge (you can run LLVM tests though, and if you merge LLVM first then you can find the revision that corresponds to your head merged with a specific clang svn revision and try running that).

Our fork has some fairly invasive changes from upstream (support for pointers that are not integers all the way from clang to the back end), so merges are quite painful and I wait longer between them than I should.

David

> On 10 Mar 2016, at 16:41, Nat! via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Hi
> 
> I am just wondering if anyone has experiences maintaining a clang fork and how you do it ?
> 
> It wasn't very easy for me to move from 3.7 to 3.8, since there were about 2000 commits I had to merge. git wasn't too clever with the merge either, finding stuff to merge in files I had never touched. In the end I reversed my mode of operation, and merged into master from my branch, using -strategy ours to keep mainline intact and preferred to reedit many of my changes.
> 
> It would appear advantageous to have some sort of continous integration, where each commit from mainline is automatically merged into my branch and then a compile is attempted. If things break, the integration stops. Otherwise it just keeps on churning. If this makes things really easier though, I don't know. Does this exist ?
> 
> Ciao
>   Nat!
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev