<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Feb 24, 2016 at 10:21 PM Pete Cooper via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Sent from my iPhone<br>
<br>
> On Feb 24, 2016, at 6:25 PM, Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I just want to clarify in case anyone is confused: I am in no way suggesting that we would use pull requests, issues, or anything else as part of the workflow for the test suite. I'm fine if folks want to talk about that later, but I really view it as a separate discussion. I'm much more interested in just leveraging the managed *hosting* of the repository<br>
This is actually the discussion I really want to happen before we move any code.<br>
<br>
Firstly, I use git and git-svn every day so I would much prefer the test suite in git. So I'm still very much a +1 for that.<br>
<br>
However, when I first started using git for llvm I had to adjust from the svn commands to the git ones and using pull/rebase instead of things like merge.<br>
<br>
Learning those things in my own repo is fine, and several times I screwed up and blew away the repo to start again from a good state. But the point is that I made those mistakes on my own machine. I'm scared of anyone else making those mistakes to the llvm test suite. That is the big advantage of the pull request model and I think that's something we should consider for any git based llvm code, including the tests.<br>
<br>
I'm also open to alternatives, but as I said, we need some way, even if it's pre-commit hooks, to make sure that anyone other that admins are behaving (not pushing too many commits at a time, no merges, etc)<br></blockquote><div><br></div><div>Yep. I have no idea what the correct process is here.</div><div><br></div><div>If folks are generally happy about this direction, I'll try to have a concrete proposal of a process. It will be *very* minimal so as to be safe and match as closely as possible the existing workflows.</div><div><br></div><div>That said, this is yet again why I think the cost/benefit tradeoff is better for the test suite. In the worst case, if we hose the repository for the test suite, it is likely to be incredibly easier to fix as we won't have 50 people all trying to get work done by landing patches at the same time as thing go sideways. And if we lose some detail of history, as long as we recover the essence, its a much less big deal.</div></div></div>