<div dir="ltr">Once you enforce a linear master branch by requiring only "git merge --no-ff", it's easy enough for a commit hook to add a monotonic tag to each commit. They're very lightweight.<div><br></div><div>Yes, someone needs to write the five lines of code to do that, but that's what you get when you use a SCM construction kit instead of a one-size-fits-all solution.</div><div><br></div><div>Incidentally, about splitting submodules out. NOOOOOOOOOO!</div><div><br></div><div>I checked out out the all in one <a href="https://github.com/chapuni/llvm-project.git">https://github.com/chapuni/llvm-project.git</a> repository. It took 2 minutes (to New Zealand) and the resulting .git directory is 581 MB. For the entire history of everything! That's utterly trivial. Less than a dollar worth of fast SSD, or maybe three cents of spinning rust.</div><div><br></div><div>Why would you want to split that up and lose atomic commits and bisect across different parts?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 17, 2015 at 3:31 PM, 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>
<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>