[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-...@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-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
