[llvm-dev] git strategy for handling the llvm-project repo together with ours

[via llvm-dev]

>> Rebasing instead of merging would also *improve* bisection, if
>> you pay attention to keeping the rebased commits buildable.
>
> Yes, that the option I mentioned as "not scalable": if you are
> actively developing, you'll have lot of code churn and making sure
> all the intermediate state of your branch are buildable on top of
> the most recent LLVM can be a lot of "unnecessary" work (I'm using
> quote because it seems subjective here).
> Also you may have O(100s) or O(1000s) commits to build and fix
> individually instead of making sure the end state is good. Take this
> over multiple years of developments potentially...

So, "it depends."  I'd naively expect that a new target would not
have O(1000s) commits.  Again, remember the context of the OP.
My recommendations for a generic downstream project (e.g., targeting
a gaming console 😊 ) would be different from the stated use-case.
 
>> I promise you, having done it, bisecting the current problem to
>> a 6-months-of-upstream-changes merge commit *really* isn't helpful.
>
> Yes: the answer to this isn't obviously rebasing to me, I rather
> merge multiple times a day (continuously if possible).

The OP clearly stated "time to time" updates, and my answer is
based on conforming to that schedule, rather than proposing an
entirely different schedule.

> Ideally you're only limited by the length of your testing suite:
> if you have a bot that continuously does "attempt-merge, test,
> and push-if-passing" you get very good bisection for the minimum
> amount of work (you only have to fix something when an upstream
> commit breaks you, and the fix is scoped to the actual commit
> that broke you). This may be what you're mentionning below with
> "small merges"?

Exactly, and that's what Sony has been doing for some years now.
We're averaging about one manual intervention per day, which is
reasonable for us; but might be excessive for a very small project
such as the OP's, who might rather schedule a big-bang merge/rebase
once every 6-12 months.  Investing time in getting individual
commits to work might well be worth the trouble in that situation.

--paulr