similar to: [Github] RFC: linear history vs merge commits

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

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

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

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

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

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 Tue, Apr 02, 2013 at 09:59:39AM -0700, Chris Lattner wrote: > On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at stellard.net> wrote: > > I would really like to see the LLVM project start to make official bug fix > > releases (e.g. 3.3.1, 3.3.2, etc.). I think that this would be useful for a > > lot of the users of LLVM, especially projects that use LLVM as a library.

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

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

greened at obbligato.org (David A. Greene) writes: > Updating LLVM - no local changes > -------------------------------- > > To update your clone to the latest LLVM sources, use git pull: > > git pull llvm-upstream That should probably be either git pull or git pull llvm-upstream master since the first is shorter and works if llvm-upstream is the upstream for the

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

FlyLanguage <flylanguage at gmail.com> writes: > 2) Nobody writing up how git should be used with the current llvm > workflow (which is not going to adapt to an SCM, but the other way > around, which is understandable.) Here is a first cut at that. Other git users, please chime in with suggestions, edits, etc. Non-git users, please ask for clarification where needed. This is

On 01/15/2020 05:03 PM, Reid Kleckner via llvm-dev wrote: > Tom Stellard told me to use `git cherry-pick -x`, and if you look at the release branches, you can see it is used, although the old style is used as well. I'm not sure what script is being used there. > I recommend updating the merge.sh script to use `git cherry-pick -x` and then deleting the merge-git.sh script. -Tom >

> On Aug 18, 2011, at 10:57 AM, David Greene wrote: >> >> Did the project ever come to a decision about making a transition to >> git? I'm trying to do some longer-term planning and it would be helpful >> to know what the roadmap is. It's stuck on: 1) A misunderstanding that global revision numbers are necessary and that 'git describe' along with

Hi, I would really like to see the LLVM project start to make official bug fix releases (e.g. 3.3.1, 3.3.2, etc.). I think that this would be useful for a lot of the users of LLVM, especially projects that use LLVM as a library. I am willing to help maintain bug fix releases, and I'm wondering if this is something that the LLVM project would officially support with a stable SVN branch and by

On Wed, 15 Jan 2020 at 18:55, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > This has simply not been true in my experience. Actually, not having > to re-send a new series is one of the main advantages that > Phabricator-based review has over the original review style for Git, > which is to send patch series via mailing lists. Interesting. If they can be committed separately,

Hi Michael, > As for actually switching to git. I see no benefit to justify the cost > of switching unless we actually take advantage of git's features. And > I've yet to see anyone propose this. Then I'll be the first. :) The benefit is that the review process would require no file copies or email attachments, shorter email conversations, no copying code during reviews to

On Wed, 15 Jan 2020 at 23:19, David Blaikie <dblaikie at gmail.com> wrote: > I don't think creating a new thread (or series of N threads) because an early patch in a series necessitate some refactoring of later patches is ideal - while patch series can/should be avoided where reasonable (& if the series is small enough/the framing/design is obvious enough, you can hold on to the