[llvm-dev] [Github] RFC: linear history vs merge commits

[Jeremy Lakeman via llvm-dev]

[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 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:

> Hi,
>
> 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
> git
> repository.  There are a lot of different topics we will need to discuss,
> but
> 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?
>
> Thanks,
> Tom
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190130/0a8e0f32/attachment.html>