Jeremy Lakeman via llvm-dev writes:
> 4. Each reviewed bug / feature must be rebased onto the current "known
> good" commit, merged into a "probably good" commit, tested by build
> bots, and only then pushed to trunk. Keeping trunk's history more
> usable, with most bad patches reworked and
Bruce Hoult via llvm-dev writes:
> How about:
>
> Require a rebase, followed by git merge --no-ff
>
> This creates a linear history, but with extra null merge commits
> delimiting each related series of patches.
>
> I believe it is compatible with bisect.
>
>
> On Jan 29, 2019, at 4:55 PM, Jeremy Lakeman via llvm-dev
> wrote:
>
> 5. When a new feature is broken up into a patch series, the series should be
> rebased then immediately merged to help identify the individual patches in
> the history graph.
Typically the LLVM development model
[Armchair observer...]
If any merges are allowed, they should be rare, have recent parent commits,
or the history graph becomes useless.
4. Each reviewed bug / feature must be rebased onto the current "known
good" commit, merged into a "probably good" commit, tested by build bots,
and only then
A linear history makes it much easier to git-bisect, since each commit can be
rolled back individually. Easier cross-project bisection is one of the
advantages of having the monorepo, and I wouldn't want to loose that.
-- adrian
___
lldb-dev mailing
