Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits
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 resubmitted instead of > reverted. If you mean having a submitted PR trigger builds and only allow merging if all builds pass, that may be doable. Of course by the time it's merged it will be against some later commit (so it should be rebased) and there's no guarantee it will build against *that* commit. But it will tend to filter out most problems. Trying to keep a branch buildable at all times is a hard problem, but the above is probably a 90% solution. -David ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits
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. > > https://linuxhint.com/git_merge_noff_option/ We've done both and I personally prefer the strict linear history by a lot. It's just much easier to understand a linear history. -David ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits
> 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 discourages merging big features in one go and instead gravitates towards breaking patches up into small, easy to reason about patches that gradually morph the code towards the goal. This makes it easier for reviewers and to track down regressions after each patch landed. For this reason we rarely have series of connected patches coming in at once. -- adrian ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits
[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
Re: [lldb-dev] [llvm-dev] [Github] RFC: linear history vs merge commits
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 list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
