similar to: [GitHub] RFC: Enforcing no merge commit policy

I think we definitely will want to support github PRs, at the very least as an _option_, even if we continue running/preferring phabricator. Github PRs are how everyone who is not already super-involved in the llvm project is going to want to contribute changes, and we ought to be as welcoming as possible to such users. On Tue, Mar 19, 2019 at 3:15 PM Roman Lebedev via cfe-dev < cfe-dev at

On 03/20/2019 10:41 AM, Zachary Turner wrote: > > > On Tue, Mar 19, 2019 at 12:00 PM Tom Stellard via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote: > > Hi, > > I would like to follow up on the previous thread[1], where there was a consensus > to disallow merge commits in the llvm github repository, and start a

It sounds like we need to get someone from the Foundation (chandlerc@, lattner@, tanya@, someone else?) to reach out to them offline about this. On Wed, Mar 20, 2019 at 11:23 AM Arthur O'Dwyer <arthur.j.odwyer at gmail.com> wrote: > On Wed, Mar 20, 2019 at 2:19 PM Tom Stellard via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> On 03/20/2019 10:41 AM, Zachary

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

Excuse my ignorance (I'm not great with Git) but how would it differ for workflows of people who use a Git repository for local work but still use `svn up + patch + svn commit <list of files>` to actually land post CR or for NFC patches, while resolving conflicts during a pull into a local (non-trunk) branch manually, after the eventual full switch to GitHub? I'm aware that SVN

On Wed, Jan 30, 2019 at 1:19 PM Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev > <cfe-dev at lists.llvm.org> wrote: > > > > Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > > > How about: > > > > > > Require a rebase, followed by git

On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Mehdi AMINI <joker.eph at gmail.com> writes: > > > What is the practical plan to enforce the lack of merges? When we > > looked into this GitHub would not support this unless also forcing > > every change to go through a pull request (i.e. no pre-receive hooks >

Hi, I mentioned this in my email last week, but I wanted to start a new thread to get everyone's input on what to do about the git-llvm script after the GitHub migration. The original plan was to require the use of the git-llvm script when committing to GitHub even after the migration was complete. The reason we decided to do this was so that we could prevent developers from accidentally

On Tue, Oct 15, 2019 at 3:47 AM Marcus Johnson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I say retire it instantly. > +1. It has never been a real requirement to use the script. Using native svn is still viable until the point of the migration. > > > On Oct 15, 2019, at 3:14 AM, Tom Stellard via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > >

On Fri, Feb 01, 2019 at 12:41:05PM -0500, Arthur O'Dwyer via cfe-dev wrote: > I know GitHub can be configured to reject force-pushes to {any, a > specific} branch. I strongly suspect that if *the maintainers of > LLVM* asked nicely, GitHub would also be able to reject > merges to {any, a specific} branch. Anyone with admin permissions in a repo can add "branch protection

On 10/09/2019 11:05 PM, Mehdi AMINI wrote: > > > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > > Hi, > > We're less than 2 weeks away from the developer meeting, so I wanted to > give an update on the GitHub migration and what's (hopefully) going to >

Oh, I'm completely in favor of making bad commits much less likely. I simply think there is a decent solution between "let everything in" and "don't let everything in unless its proven to work everywhere" that gets 90% of the improvement. The complexity of guaranteeing a buildable branch is high. If someone wants to take that on, great! I just don't think we

On 20 Mar 2019, at 18:23, Arthur O'Dwyer via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Server-side hooks are the answer to this problem. There is no problem. You just use a server-side hook. It is quite unlikely that GitHub will allow LLVM (or any other project) to run arbitrary post-receive hooks. It is far more likely that they will give an option that disables the merge

One is expected to use `git llvm push`. For more information, please see: https://llvm.org/docs/GettingStarted.html#for-developers-to-commit-changes-from-git > On Sep 3, 2019, at 7:06 PM, David Greene via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > What is the expected way to do commits? Do we push directly to master > after a rebase? I know there has been talk of using

I'm also a strong proponent of not requiring the wrapper. The linear history piece was important enough to make the cost worth it.  The extra branches piece really isn't.  If someone creates a branch that's not supposed to exist, we just delete it. No big deal.  It will happen, but the cost is so low I don't worry about it. There's a bunch of things in our developer policy

On Thu, Oct 10, 2019 at 1:14 PM Jordan Rupprecht <rupprecht at google.com> wrote: > > > On Thu, Oct 10, 2019 at 12:29 PM Tom Stellard via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 10/10/2019 11:40 AM, Mehdi AMINI wrote: >> > >> > >> > On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard <tstellar at redhat.com >>

Just to clarify: All the LLVM incubator repositories have "enforce linear history" enabled. Neither "Squash and Merge" or "Rebase and Merge" results in a Merge commit in the git history. Steve On Fri, Sep 11, 2020 at 3:32 PM Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > On Fri, Sep 11, 2020 at 6:12 PM Renato Golin <rengolin at

Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> 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

On 10/10/2019 11:40 AM, Mehdi AMINI wrote: > > > On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard <tstellar at redhat.com <mailto:tstellar at redhat.com>> wrote: > > On 10/09/2019 11:05 PM, Mehdi AMINI wrote: > > > > > > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at

On 01/22, David Greene via cfe-dev wrote: > Renato Golin via cfe-dev <cfe-dev at lists.llvm.org> writes: > > >> My understanding from other people's comments (I've not tried it myself) is that updating a patch series in github is problematic - that it sends new/separate review email rather than being able to associate each patch in the series with ongoing review