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 simulate inline comments, and no need to "git rebase" to push to the top of svn. I wouldn't be surprised if the difference was so significant that folks would stop using the llvm-commits list altogether. To see what changed, you'd check the github mirror, and to contribute you could post a link to llvmdev (not too noisy). For example, say github's llvm-mirror was a contributor's fork. The review process might look like this: Contributor: Please review my patch: https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 Maintainer: Adds inline comments with online tool. Then when patch is looking good: $ git fetch https://github.com/llvm-mirror/llvm.git $ git cherry-pick 4823be3be1d87632fbd51ce8e51a58ee5e44b115 $ git push Thanks, Greg On Thu, Nov 15, 2012 at 11:35 AM, Michael Spencer <bigcheesegs at gmail.com>wrote:> On Thu, Nov 15, 2012 at 10:48 AM, David Chisnall > <David.Chisnall at cl.cam.ac.uk> wrote: > >> > I think svn works better than git as an authoritative upstream > >> > >> Would you mind expanding on this? What problem specifically is being > solved? Linus and Guido both use DVCS's and the authoritative upstream is > whatever URL the BDFL says it is. > > > > Monotonic version numbers are the biggest advantage. It is easy to see > that r1234432 contains the bug fix introduced in r1234430. It is very hard > to see if version 23bef194ac contains the bug fix added in 23bef19412. > This makes interaction with bugzilla and so on much easier. If someone > says 'please test r1245145 - should be fixed' you can easily check whether > you are running r1245145 or newer. > > > > David > > git branch --contains 23bef19412 > > This will tell you which of your branches have that commit and > highlight the current branch you are on. > > Git also has monotonically increasing identifiers for each commit. The > time stamp. Which I find much more informative than a revision number > split between multiple repositories. > > 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. So for now, git-svn works for me. > > - Michael Spencer >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/f404b205/attachment.html>
On Thu, Nov 15, 2012 at 12:01 PM, Greg Fitzgerald <garious at gmail.com> wrote:> 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. :)I'd suggest you/others read the previous thread discussing this issue. It's a bit tricky to link to a whole thread in the llvm-dev mail archive, but here's one part of it: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.html> The benefit is that the review process would require no file copies or email > attachments, shorter email conversations, no copying code during reviews to > simulate inline comments, and no need to "git rebase" to push to the top of > svn. I wouldn't be surprised if the difference was so significant that > folks would stop using the llvm-commits list altogether. To see what > changed, you'd check the github mirror, and to contribute you could post a > link to llvmdev (not too noisy).Essentially that's precisely what we want to avoid. The intention is to keep discussion & review in the shared public view & keep the codebase in a (mostly) singular state. The transition to git would have to be justified on its merits while still preserving that workflow, not while working against it. (I'm not sure how folks would stop using llvm-commits all together, if we still have as much shared development there would still be a push email for every shared commit, an email for every review request, and if the reduction in email was because review happened off-list, that would be a loss, not a benefit)> For example, say github's llvm-mirror was a contributor's fork. The review > process might look like this: > > Contributor: > Please review my patch: > https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 > > Maintainer: > Adds inline comments with online tool. Then when patch is looking good: > $ git fetch https://github.com/llvm-mirror/llvm.git > $ git cherry-pick 4823be3be1d87632fbd51ce8e51a58ee5e44b115 > $ git push > > Thanks, > Greg > > > On Thu, Nov 15, 2012 at 11:35 AM, Michael Spencer <bigcheesegs at gmail.com> > wrote: >> >> On Thu, Nov 15, 2012 at 10:48 AM, David Chisnall >> <David.Chisnall at cl.cam.ac.uk> wrote: >> >> > I think svn works better than git as an authoritative upstream >> >> >> >> Would you mind expanding on this? What problem specifically is being >> >> solved? Linus and Guido both use DVCS's and the authoritative upstream is >> >> whatever URL the BDFL says it is. >> > >> > Monotonic version numbers are the biggest advantage. It is easy to see >> > that r1234432 contains the bug fix introduced in r1234430. It is very hard >> > to see if version 23bef194ac contains the bug fix added in 23bef19412. This >> > makes interaction with bugzilla and so on much easier. If someone says >> > 'please test r1245145 - should be fixed' you can easily check whether you >> > are running r1245145 or newer. >> > >> > David >> >> git branch --contains 23bef19412 >> >> This will tell you which of your branches have that commit and >> highlight the current branch you are on. >> >> Git also has monotonically increasing identifiers for each commit. The >> time stamp. Which I find much more informative than a revision number >> split between multiple repositories. >> >> 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. So for now, git-svn works for me. >> >> - Michael Spencer > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Greg Fitzgerald <garious at gmail.com> writes:>> I've yet to see anyone propose this.Oh, many people have proposed using git's features.> 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 simulate inline comments, and no need to "git rebase" to > push to the top of svn.I'm not sure this is actually true. Yes, you can ask people to pull your changes and review them, but that misses the value of other people chiming in when they see your code on the e-mail list. And for practicality, "git rebase" will almost certainly be necessary before pushing to upstream master.> I wouldn't be surprised if the difference was so significant that > folks would stop using the llvm-commits list altogether. To see what > changed, you'd check the github mirror, and to contribute you could > post a link to llvmdev (not too noisy).I think a possibly more productive way to do reviews would be through something like Gerrit. I believe there are far more important git advantages for llvm, many of which I have listed before. These include but are not limited to: - A natural system for small, incremental commits. The svn model generally discourages this kind of development while the git model encourages it. - Tools for responding to reviews. These include git rebase -i and git add -i. - Easier third-party merging. Merging via git merge/rebase is MUCH simpler than merging a tarball from svn. I know the llvm leaders don't seem to care about this but it is a real issue for many users. - Ease of fork/merge. git makes it easy to experiment with long-lived development branches. svn forces all development into trunk which limits experimentation and innovation. -David
On 15 Nov 2012, at 12:31, <dag at cray.com> wrote:> - Easier third-party merging. Merging via git merge/rebase is MUCH > simpler than merging a tarball from svn. I know the llvm leaders > don't seem to care about this but it is a real issue for many users. > > - Ease of fork/merge. git makes it easy to experiment with long-lived > development branches. svn forces all development into trunk which > limits experimentation and innovation.Neither of these are true. There is nothing stopping people from working in branches in svn and merging from branches is easy. The advantage with git is that it's very easy to have your fork somewhere where no one else sees it and your changes get lost and forgotten. Your point about small incremental commits is also untrue. svn encourages small incremental commits and, more importantly, encourages small incremental pushes upstream. This is something we want to encourage: we don't want to make it easier for people to have private forks than it is to push them upstream. David
> I'd suggest you/others read the previous thread discussing this issue. > It's a bit tricky to link to a whole thread in the llvm-dev mail > archive, but here's one part of it: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.htmlMaybe I should add this to the FAQ? Does this look good?: Why don't you move from svn to git? ============================= Please read the following discussions about the issue, and think carefully before bringing it up on the list: * http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.html * ... others ... -- Sean Silva On Thu, Nov 15, 2012 at 3:27 PM, David Blaikie <dblaikie at gmail.com> wrote:> On Thu, Nov 15, 2012 at 12:01 PM, Greg Fitzgerald <garious at gmail.com> wrote: >> 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. :) > > I'd suggest you/others read the previous thread discussing this issue. > It's a bit tricky to link to a whole thread in the llvm-dev mail > archive, but here's one part of it: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.html > >> The benefit is that the review process would require no file copies or email >> attachments, shorter email conversations, no copying code during reviews to >> simulate inline comments, and no need to "git rebase" to push to the top of >> svn. I wouldn't be surprised if the difference was so significant that >> folks would stop using the llvm-commits list altogether. To see what >> changed, you'd check the github mirror, and to contribute you could post a >> link to llvmdev (not too noisy). > > Essentially that's precisely what we want to avoid. The intention is > to keep discussion & review in the shared public view & keep the > codebase in a (mostly) singular state. The transition to git would > have to be justified on its merits while still preserving that > workflow, not while working against it. > > (I'm not sure how folks would stop using llvm-commits all together, if > we still have as much shared development there would still be a push > email for every shared commit, an email for every review request, and > if the reduction in email was because review happened off-list, that > would be a loss, not a benefit) > >> For example, say github's llvm-mirror was a contributor's fork. The review >> process might look like this: >> >> Contributor: >> Please review my patch: >> https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 >> >> Maintainer: >> Adds inline comments with online tool. Then when patch is looking good: >> $ git fetch https://github.com/llvm-mirror/llvm.git >> $ git cherry-pick 4823be3be1d87632fbd51ce8e51a58ee5e44b115 >> $ git push >> >> Thanks, >> Greg >> >> >> On Thu, Nov 15, 2012 at 11:35 AM, Michael Spencer <bigcheesegs at gmail.com> >> wrote: >>> >>> On Thu, Nov 15, 2012 at 10:48 AM, David Chisnall >>> <David.Chisnall at cl.cam.ac.uk> wrote: >>> >> > I think svn works better than git as an authoritative upstream >>> >> >>> >> Would you mind expanding on this? What problem specifically is being >>> >> solved? Linus and Guido both use DVCS's and the authoritative upstream is >>> >> whatever URL the BDFL says it is. >>> > >>> > Monotonic version numbers are the biggest advantage. It is easy to see >>> > that r1234432 contains the bug fix introduced in r1234430. It is very hard >>> > to see if version 23bef194ac contains the bug fix added in 23bef19412. This >>> > makes interaction with bugzilla and so on much easier. If someone says >>> > 'please test r1245145 - should be fixed' you can easily check whether you >>> > are running r1245145 or newer. >>> > >>> > David >>> >>> git branch --contains 23bef19412 >>> >>> This will tell you which of your branches have that commit and >>> highlight the current branch you are on. >>> >>> Git also has monotonically increasing identifiers for each commit. The >>> time stamp. Which I find much more informative than a revision number >>> split between multiple repositories. >>> >>> 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. So for now, git-svn works for me. >>> >>> - Michael Spencer >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> For example, say github's llvm-mirror was a contributor's fork. The review > process might look like this: > > Contributor: > Please review my patch: > https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 > > Maintainer: > Adds inline comments with online tool. Then when patch is looking good: > $ git fetch https://github.com/llvm-mirror/llvm.git > $ git cherry-pick 4823be3be1d87632fbd51ce8e51a58ee5e44b115 > $ git pushMost development is not "some contributor's fork". What you suggest works great for the occasional drive-by contributors, but most development is not from drive-by's. -- Sean Silva On Thu, Nov 15, 2012 at 3:01 PM, Greg Fitzgerald <garious at gmail.com> wrote:> 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 > simulate inline comments, and no need to "git rebase" to push to the top of > svn. I wouldn't be surprised if the difference was so significant that > folks would stop using the llvm-commits list altogether. To see what > changed, you'd check the github mirror, and to contribute you could post a > link to llvmdev (not too noisy). > > For example, say github's llvm-mirror was a contributor's fork. The review > process might look like this: > > Contributor: > Please review my patch: > https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 > > Maintainer: > Adds inline comments with online tool. Then when patch is looking good: > $ git fetch https://github.com/llvm-mirror/llvm.git > $ git cherry-pick 4823be3be1d87632fbd51ce8e51a58ee5e44b115 > $ git push > > Thanks, > Greg > > > On Thu, Nov 15, 2012 at 11:35 AM, Michael Spencer <bigcheesegs at gmail.com> > wrote: >> >> On Thu, Nov 15, 2012 at 10:48 AM, David Chisnall >> <David.Chisnall at cl.cam.ac.uk> wrote: >> >> > I think svn works better than git as an authoritative upstream >> >> >> >> Would you mind expanding on this? What problem specifically is being >> >> solved? Linus and Guido both use DVCS's and the authoritative upstream is >> >> whatever URL the BDFL says it is. >> > >> > Monotonic version numbers are the biggest advantage. It is easy to see >> > that r1234432 contains the bug fix introduced in r1234430. It is very hard >> > to see if version 23bef194ac contains the bug fix added in 23bef19412. This >> > makes interaction with bugzilla and so on much easier. If someone says >> > 'please test r1245145 - should be fixed' you can easily check whether you >> > are running r1245145 or newer. >> > >> > David >> >> git branch --contains 23bef19412 >> >> This will tell you which of your branches have that commit and >> highlight the current branch you are on. >> >> Git also has monotonically increasing identifiers for each commit. The >> time stamp. Which I find much more informative than a revision number >> split between multiple repositories. >> >> 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. So for now, git-svn works for me. >> >> - Michael Spencer > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Sean Silva <silvas at purdue.edu> writes:>> For example, say github's llvm-mirror was a contributor's fork. The review >> process might look like this: >> >> Contributor: >> Please review my patch: >> https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 >> >> Maintainer: >> Adds inline comments with online tool. Then when patch is looking good: >> $ git fetch https://github.com/llvm-mirror/llvm.git >> $ git cherry-pick 4823be3be1d87632fbd51ce8e51a58ee5e44b115 >> $ git push > > Most development is not "some contributor's fork".Well, in the git model every developer has a fork.> What you suggest works great for the occasional drive-by > contributors, but most development is not from drive-by's.Not sure what you mean by "drive-by" but in git this is really irrelevant, I think. -David
LLVM Community,> http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.htmlThis was extraordinarily valuable in learning to understand the situation - thank you David Blaikie for pointing me to it. A few key snippets: "Because I optimize for the code reviewer, not the patch submitter," Chris Lattner "Forcing transitioning to git makes no sense for a lot of us - for example, we have lots of scripts that depend on svn revision numbers," Jason Kim "Let me say this again: We are not fundamentally changing the development policy around LLVM," Chris Lattner My interpretations, which later in this long email, I'll assume as premises to a recommended action: * Chris finds code reviewers to be exceptionally rare and the community's most valuable participants. My previous "spork" suggestion would be a decision made my maintainers, not influenced by patch-contributors, and would only happen if the maintainers felt the transition made it easier for them to review and/or commit patches. * Dropping SVN would be expensive for some. Instead of dropping SVN, it is more reasonable to make git the central repo and have SVN mirror git. * A linear history is highly valued by Chris and many members of the community. My input (or from my perspective, my output): In my humble opinion, there is a one biggest problem with git-svn and svn. It requires the maintainer to rebase before committing, and in git, this changes the the patch's unique ID. Changing the ID creates a serious problem, one which forces the private fork to make an early decision about contributing back to the community. The private fork must decide, "do we want this patch today or would we rather wait for it to come in through a "fast-forward" of the community's repository?" If we choose to accept the patch locally, we have another decision to make, "do we want to deal with merge conflicts after the patch makes it through the community's review process, or should we just keep it private and enjoy easy automatic merges until the community eventually finds the same bug and redundantly makes a similar fix?" I hope you see this as not a Good Thing for the community. The policy of rebasing provides private forks incentive *not* to contribute patches. Please oh please, do not reply saying "but that's just selfish." The point I am hoping to illustrate is only that this incentive exists, and it is a consequence of policy. However, one could argue that the same policy, to always rebase, provides incentive not to fork at all. That is, it is easier to contribute to the community than to make a private patch and risk merge conflicts. Indeed, but one problem, a fact of software: The private fork of any project will always and only exist as a mechanism to meet functional requirements and/or schedule that do not align with the official "mainline". More concretely, if I have an upcoming release planned and have a bug-fix that affects the correctness of the compiler, I will most certainly add it to my private fork and not wait on a community review. At this point, I actually have incentive to stop the code review process and hope the community never finds and fixes my bug. My life is easier when I choose not to contribute, and this a direct consequence of the policy decision to rebase instead of merge. But rebasing is fundamental in providing a linear history, right? I question the validity of this popular argument, and argue this is just a tooling issue. The very fact that a rebase can often be achieved automatically and without conflicts should send a strong signal that this may be true. At it turns out, the git object tree does encode a linear history. But this is not obvious! "git log" makes an awkward design decision in ordering commits by date. Instead, I think it should be ordered by merge, or specifically, a pre-order, depth-first traversal of the commit tree. I believe people care more about when the patch entered their own repository than when the author made the commit to his or hers. Proposal: a slow, multistep, backward-compatible transition to remove the disincentive to contribute patches from private forks: Step 1: Demonstrate "git log" or a similar tool can produce a linear history in the presence of merging. This may already be possible. Step 2: Swap the roles of git and svn. Make svn the mirror and git the central repository, and update the online documentation accordingly. In this step, do not change any policies and demand anyone with commit access to maintain a linear history. This restriction is necessary for the svn mirror, but aims to give everyone with svn-dependencies a strong hint that LLVM's use of svn is on its way out. Step 3: Once all svn automation dependencies have been dropped, discontinue the svn mirror. Relax the "always rebase" policy and ask code-owners to start preferring merges to rebasing. If the community is willing to make this transition, I commit to coordinating a worldwide decentralized party celebrating our successful move to decentralized version control. Thank you for your time, Greg Fitzgerald P.S. tl;dr, right?