<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 17, 2015 at 2:31 AM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Even though git could be used in the same way as svn, why migrate just to<br>
> re-create the current workflow? Doesn't make too much sense to me. A<br>
> migration to git would have to include some other benefit, not just be<br>
> change for the sake of it.<br>
<br>
</span>I think our routine workflow suffers quite a bit from the svn<br>
emphasis. Sending text patches is all very well from a portability<br>
point, but it makes applying someone else's commits rather annoying<br>
(particularly for commit, but even for testing):<br>
<br>
1. Download the patch.<br>
2. Remember where you put it (~/Downloads, ~, ~/Documents -- depends<br>
on exactly what program downloaded it) and what the name of the file<br>
was.<br>
3. Either look or randomly guess what -pN you need to apply it.<br>
4. Check things.<br>
5. Open the blasted file again to recover the commit message<br>
(frequently weirdly indented because that's what "git show" produces).<br>
Or make one up.<br>
6. Commit with that via copy/paste.<br>
7. Hope you didn't forget to "git/svn add" the new test before committing.<br>
<br>
This is all you can do in svn (as far as I'm aware), but it's<br>
something git has solutions for. Some unified "git fetch" available<br>
for this would be very useful for example, even if we do decide a<br>
world without monotonic numbers is too scary for us.<br></blockquote><div><br></div><div>Personally one of the things I really like about LLVM is precisely this "human" aspect of applying patches from the mailing list for people without commit access. It adds some extra human redundancy around all-important new-contributor patches where almost by definition you will need to provide some human feedback to the contributor in order to help their next patch be better (and determining what feedback to give and cogently formulating it is much more work than copypasting some stuff or guessing a -pN).</div><div><br></div><div>Having patch application fully automated only matters IMO if this this form of patch application is the primary way work gets integrated into the mainline; but that is not the case, since the primary way work gets committed on the mainline in the LLVM project is by trusted contributors with post-commit review (compare to e.g. Linux where patch application *is* the primary way that work gets integrated into the mainline, so it makes sense to have the process highly automated).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>