similar to: FYI, no more merge commits

Hi, At the LLVM dev meeting, some people discussed the possibility of having pre-push and/or pre-commit hooks to avoid messing up the history when we move on to the monorepo. One of the concerns was about people starting to push merge commits and unsquashed commits upstream, resulting in a messy history. I had volunteered to write a hook that would check for the absence of merge commits in the

I noticed that the upstream version of our update script had evolved in git.git, so I merged their changes into ours. I haven't installed this server-side hook yet, because I don't know if your process requires moving tags. Let me know and I'll install the new version. >From 260c6c70a5b73c3ab7be705ed9da05b9c0b060fa Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at

On Wed, 30 Oct 2019, Sameer Sahasrabuddhe via llvm-dev wrote: > October 30, 2019 5:58 AM, "Alex L via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > >> Oh, this explains it! Unfortunately one of our engineers made a mistake, and pushed the ref to >> wrong remote while resolving a merge conflict on https://github.com/apple/llvm-project (pushed to >>

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

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

We've all wanted to be able to tweak a few server-side settings, without having to find/ask/wait for someone do something manually on the server. With this change to ovirt's "update" hook, you can now do just that by pushing a specially formed tag to the remote repository. (once this hook is installed) If that tag meets several criteria, the "update" hook will run the

On 01/24, Renato Golin wrote: > On Fri, 24 Jan 2020 at 17:11, Doerfert, Johannes <jdoerfert at anl.gov> wrote: > > As I understand it, the GH model is to amend a new commit to your PR > > which addresses the review comments. The "problem" is that "we" are used > > to the force push model in which each commit is always as "clean and self > >

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

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

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

Has anyone tried out reviewable.io yet? It integrates with GitHub pull requests, but provides a separate UI for doing the review which promises to fix a lot of the issues encountered with Github's review interface. Some of the things it claims to support which seem like important additions: - Tracking the resolved status of each discussion point - Rebasing a PR without losing review history.

Jeremy Lakeman via llvm-dev <llvm-dev at lists.llvm.org> 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 >

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. We can enforce it for pull requests, but not for direct pushes to the master branch, so we will have to

The LLVM incubator projects have been using github PRs for reviews and so far haven't really seen any significant issues. The biggest confusion so far has not been with reviews but with the difference between "rebase and merge" and "squash and mere". We have used basically 3 different processes: Method 1: start a review with one commit on a new branch (typically in a

Hi, On Wed, Jan 8, 2020 at 6:54 PM Finkel, Hal J. via llvm-dev < llvm-dev at lists.llvm.org> wrote: > FYI to everyone: If you have things that you would like to see done > before a merge of Flang, please reply with as many details as you have > time to provide (and if you have things that you would like to see done > soon, but you're comfortable with them happening after

Hi, Following Evan's recommendation, I'd like to notify maintainers of out-of-tree targets that a patch is currently being discussed on llvm-commits (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130114/162561.html) that may affect your target, since it requires targets to explicitly state the size of the stack slot used to save callee-save registers. Eli