[llvm-dev] [RFC] One or many git repositories?

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 20 18:36:18 PDT 2016


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

“git log” would show the full history with a sparse checkout, including the commits that are touching a subdirectory that is not checked out.
From the top of the project you’d have to type “git log llvm” to have only the llvm history. I’m not sure if there is a config/alias for that, but a custom git-log script could read the sparse-checkout config to filter it by default.


— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160720/896dc527/attachment.html>


More information about the llvm-dev mailing list