[llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?

[Robinson, Paul via llvm-dev]

> -----Original Message-----
> From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David
> Chisnall
> Sent: Tuesday, June 07, 2016 2:52 AM
> To: Bruce Hoult
> Cc: Robinson, Paul; llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?
> 
> On 7 Jun 2016, at 09:34, Bruce Hoult via llvm-dev <llvm-
> dev at lists.llvm.org> wrote:
> >
> > Have you tried the git-imerge add-on?
> 
> You beat me to it - I was just about to suggest the same thing.  Merges
> from LLVM upstream have been a lot more CPU-intensive, but a lot less
> human-intensive since I started using it.  It’s worth noting though that
> not having the clang repo as a submodule makes bisection very hard for
> clang-related changes.

I did look at git-imerge, and very much liked what I saw.
However our local repo is not set up like upstream, and it's not clear
we could paste everything together with imerge in a straightforward way,
or possibly even make it work at all.
It is clear (and we have the hardware resources to support it) that we
can iterate merging each individual upstream commit.  If we were starting
over from scratch instead of building on what we already have, I'd much
rather do it differently!

I could see git-imerge working extremely well for downstream projects that
were essentially a series of patches on top of the upstream projects.
--paulr

> 
> If you have upstream and downstream, git-imerge’s rebase-with-history is
> very useful, as your tree ends up looking as if it’s been rebased onto
> upstream, but downstream users can still pull from any of your pre-merge
> commits and merge (or rebase) that into their own tree.
> 
> David