<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 20, 2016 at 6:26 PM, Justin Bogner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Justin Lebar <<a href="mailto:jlebar@google.com">jlebar@google.com</a>> writes:<br>
>> Running the same 'git checkout' commands on multiple repos has<br>
>> always been sufficient to manage the multiple repos so far<br>
><br>
> Huh.  It definitely hasn't worked well for me.<br>
><br>
> Here's the issue I face every day.  I may be working on (unrelated)<br>
> changes to clang and llvm.  I update my llvm tree (say I checked in a<br>
> patch, or I want to pull in changes someone else has checked in).  Now<br>
> I want to go back to hacking on my clang stuff.  Because my clang<br>
> branch is not connected to a specific LLVM revision, it no longer<br>
> compiles.  I'm trying to build an old clang against a new llvm.<br>
><br>
> Now I have to pull the latest clang and rebase my patches.  After I<br>
> deal with rebase conflicts (not what I wanted to do at the moment!),<br>
> I'm in a new state, which means when I build my ccache is no help.<br>
> And when I run the clang tests, I don't know whether to expect test<br>
> failures.  So then I have to pop of my patches and run at head...<br>
> (Maybe I have to update clang!  In which case I also have to update<br>
> llvm...)<br>
><br>
> This would all be solved with zero work on my part if llvm and clang<br>
> were in one repository.  Then when I switched to working on my clang<br>
> patches, I would automatically check out a version of LLVM that is<br>
> compatible.<br>
><br>
> I think this is the main thing that people aren't getting.  Maybe<br>
> because it's never been possible before to have a workflow like this.<br>
> But having a git branch that you can check out and immediately build<br>
> -- without any rebasing, re-syncing, or other messing around -- is<br>
> incredibly powerful.<br>
<br>
</div></div>I don't know man, when I create a branch to save my clang work I just<br>
create a branch with the same name in all the other repos I have checked<br>
out, then it just stays in the state I left it in as I go do other<br>
stuff. This kind of problem just hasn't really come up for me.<br></blockquote><div><br></div><div>It has for me, and it is a serious problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
> Please let me know if this is still not clear -- it's kind of the key point.<br>
><br>
> As I said, you can accomplish this with submodules, too, but it<br>
> requires the complex hackery from my original email.<br>
><br>
> To me, this is not at all a minor inconvenience.  It's at least an<br>
> hour of wasted time every week.<br>
><br>
>> I haven't tried the options jlebar has described to deal with these<br>
>> - sparse checkouts and whatnot, but they seem like an equivalent<br>
>> amount of work/learning curve as writing a script that cd's to<br>
>> several directories and runs the same git command in each.<br>
><br>
> I'll send sparse checkout instructions separately.  But my example<br>
> submodules commands are not at all equivalent to a script that cd's<br>
> into several directories and runs a git command in each, and I think<br>
> this is the main point of confusion.  (In fact you wouldn't need to<br>
> write such a script; it's just "git submodule foreach".)<br>
><br>
> The submodules commands creates a single branch in the umbrella repo<br>
> that encompasses the checked-out state of *all the LLVM subrepos*.  So<br>
> you can, at a later time, check out this branch in the umbrella repo<br>
> and all the clang, llvm, etc. bits will be identical to the last time<br>
> you were on the branch.<br>
><br>
> If all you want is to continue using git the way you use it now, the<br>
> multiple git repos gets you that (as does a sparse checkout on the<br>
> single repo).  My point is that, the move to git opens up a new, much<br>
> more powerful workflow with branches that encompass both llvm and<br>
> clang state.  We can do this with or without submodules, but using<br>
> submodules for this is far more awkward than using a single repo.<br>
<br>
</div></div>If I do `git log` in a sparse checkout that just has LLVM, will it only<br>
show me LLVM commits? That is, how easy is it to filter out the<br>
clang/lldb/subproject-X commits from a log? Negative globs are kind of<br>
awkward.<br></blockquote><div><br></div><div>It is extremely easy (even with a full checkout): `git log llvm/`</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">
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>