[llvm-dev] [Github] RFC: linear history vs merge commits
Jeremy Lakeman via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 29 16:55:40 PST 2019
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 pushed to trunk. Keeping trunk's history more usable, with
most bad patches reworked and resubmitted instead of reverted.
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.
On Wed, 30 Jan 2019 at 09:04, Tom Stellard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> As part of the migration of LLVM's source code to github, we need to update
> our developer policy with instructions about how to interact with the new
> repository. There are a lot of different topics we will need to discuss,
> I would like to start by initiating a discussion about our merge commit
> policy. Should we:
> 1. Disallow merge commits and enforce a linear history by requiring a
> rebase before push.
> 2. Allow merge commits.
> 3. Require merge commits and disallow rebase before push.
> I'm going to propose that if we cannot reach a consensus that we
> adopt policy #1, because this is essentially what we have now
> with SVN.
> What does everyone think?
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev