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

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

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.

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

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

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

> On Jun 2, 2016, at 11:03 AM, dag at cray.com wrote: > > Tim Northover via cfe-dev <cfe-dev at lists.llvm.org> writes: > >> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev >> <lldb-dev at lists.llvm.org> wrote: >>> Apparently I wasn't very clear: llvm and clang (and the others >>> projects) would be simple decoupled, individual 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've created a text file[1] in the SVN repository that developers can update in order to request commit access to the GitHub repository. All you need to do is add a line in the form of $SVN_USERNAME:$GITHUB_USERNAME Please add your information to this file before SVN becomes readonly on October 21 to avoid a gap in commit access. More details can be found in the phabriactor review[2]

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

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