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/
Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes:> 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".I think this is all coverd in the existing developer guide. The whole goal of this transition is that that document doesn't change, except when it comes to describing source control commands.> It should also mention what happens on llvm.org, like "when you do a > git push, here's what's going to happen".I'm not understanding you here. What's going to happen besides, "the change gets integrated, a build gets kicked off and a post gets made to llvm-commits?"> 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".That's what's in the document I posted, I think. If I need to clarify it, I am happy to do so.> 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).Right. I wrote the document for people who ar not git experts and want to better understand how a transition would work. -Dave
greened at obbligato.org (David A. Greene) writes:>> It should also mention what happens on llvm.org, like "when you do a >> git push, here's what's going to happen". > > I'm not understanding you here. What's going to happen besides, "the > change gets integrated, a build gets kicked off and a post gets made to > llvm-commits?"That's the kind of things I was refering to, yes. -- Matthieu Moy http://www-verimag.imag.fr/~moy/