>> 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 based on my notes on working with LLVM via > git-svn, modified to assume native git. There are hundreds of ways to > design a workflow that works with the current review process. This is > but one. > > We should add this to the web page once it's polished if we make the > transition to git.Great that you work on this, but I don't quite get the approach, nor some of your examples (which seems buggy). I feel that: a) We don't need another git tutorial - there's a lot of really good ones out there, even ones explaining git from the perspective of a current SVN user. b) We need a document explaining how patches are reviewed and referred to, what commit rules (and hooks) are in place and how this would work in a git world. It would be short and sweet.
FlyLanguage <flylanguage at gmail.com> writes:> Great that you work on this, but I don't quite get the approach, nor > some of your examples (which seems buggy).Some examples may be buggy. If you find problems, let me know!> a) We don't need another git tutorial - there's a lot of really good > ones out there, even ones explaining git from the perspective of a > current SVN user.A request went out for something specific to LLVM. That's why I wrote this. If you have tutorials you think are particularly good, post them here and I'll add them to the Resources list.> b) We need a document explaining how patches are reviewed and referred > to, what commit rules (and hooks) are in place and how this would work > in a git world. It would be short and sweet.I'm not exactly sure what you're asking for. My assumption is that the hooks in place for git are the same hooks we currently have for svn, ported to work with git. Is there something else we need? The review process over e-mail works exactly as it does now. I don't understand why we need a different document for that when using git. The stated requirement for moving to git is that the review process doesn't change. When you say "how patches are referred to" do you mean actually patches (text files) or commits. Commits are referenced by commit ID, just like today. Patches are referred to by name and/or file/attachment, just like today. The goal of the document I wrote is to explain how an LLVM developer would use git day-to-day to integrate into the existing LLVM review process. The assumption I made when writing it is that the typical LLVM developer has no knowledge of git. That's why it's tutorial-like. It also serves as a concrete example of how git can work with the existing review process. This can help boost the confidence of those wary about a git transition that such a transition is workable. I feel I've missed something fundamental about your request. What is it? :) -Dave
greened at obbligato.org (David A. Greene) writes:>> b) We need a document explaining how patches are reviewed and referred >> to, what commit rules (and hooks) are in place and how this would work >> in a git world. It would be short and sweet. > > I'm not exactly sure what you're asking for. My assumption is that the > hooks in place for git are the same hooks we currently have for svn, > ported to work with git. Is there something else we need?I don't really know LLVM's best practices, so I can't say exactly _what_ should go in such document, but I think it's important to distinguish two things: 1) How one should behave wrt other LLVM developers, with rules like "please send patches this way" or "don't git push something that hasn't been reviewed before", or "here's how you may get a patch accepted if you're not an LLVM developer". It should also mention what happens on llvm.org, like "when you do a git push, here's what's going to happen". 2) Optionnaly, some technical hints on how to do 1) properly, like "if you're asked to send a revised version, git rebase -i and git commit --amend are your friends". 1) should be something people really agree on, and it people want it to be as close as possible to the existing flow. 2) is a matter of personnal choice (advanced Git users won't need to read it). -- Matthieu Moy http://www-verimag.imag.fr/~moy/