[cfe-dev] [llvm-dev] [lldb-dev] [GitHub] RFC: Enforcing no merge commit policy

[Hubert Tong via cfe-dev]

On Wed, Mar 20, 2019 at 6:25 PM Kristina Brooks via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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 think SVN does not factor at all into where this thread is going: This is
about what happens after the switch.


>
> I'm aware that SVN operates using the lock model as opposed to Git
> essentially making the
> history linear; Are merge commits multiple commits that are landed as part
> of a single
> Git "push" (ie. unsquashed), or attempts to do anything that would result
> in a creation
> or merging of a branch on the remote?
>
Git history is not inherently linear. Merge commits are where different
branches of development are merged together. Instead of merging different
branches together (and retaining the history of the branches), it is
possible to chose one as the "base" branch and "rebase" the other onto that
branch. The Git history then appears to be linear.


>
> Thank you.
>
> On 3/20/2019 6:53 PM, Tom Stellard via llvm-dev wrote:
> > On 03/20/2019 11:38 AM, Zachary Turner wrote:
> >> It sounds like we need to get someone from the Foundation (chandlerc@,
> lattner@, tanya@, someone else?) to reach out to them offline about this.
> >>
> >
> > Yes, we will try to reach out to GitHub directly about this, but I still
> > think we need some kind of contingency plan in case pre-receive hooks
> > or even a new kind of branch protection won't be an option for us.
> >
> > -Tom
> >
> >> On Wed, Mar 20, 2019 at 11:23 AM Arthur O'Dwyer <
> arthur.j.odwyer at gmail.com <mailto: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 <mailto:cfe-dev at lists.llvm.org>> wrote:
> >>
> >>         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> <mailto:
> 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 discussion
> >>         >     about how we should enforce this policy.
> >>         >
> >>         >     Unfortunately, GitHub does not provide a convenient way
> to fully enforce this policy.
> >>         >
> >>         >
> >>         > Why isn't this enforceable with a server-side pre-receive
> hook?
> >>
> >>         GitHub[1] only supports pre-receive hooks in the 'Enterprise
> Server'
> >>         plan, which is for self-hosted github instances.
> >>
> >>
> >>     AIUI, the GitHub team is perfectly willing to help out the LLVM
> project in whatever way LLVM needs, including but not limited to turning on
> server-side hooks for us.
> >>     https://twitter.com/natfriedman/status/1086470665832607746
> >>
> >>     Server-side hooks are *the *answer to this problem. There is no
> problem. You just use a server-side hook.
> >>
> >>     (Whether or not to use GitHub PRs is an orthogonal question. You
> can use hooks with PRs, or hooks without PRs; PRs with hooks, or PRs
> without hooks.)
> >>
> >>     –Arthur
> >>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190320/bd7fbf1f/attachment.html>