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

David Chisnall via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 21 08:22:43 PDT 2016


On 21 Jul 2016, at 16:11, James Y Knight <jyknight at google.com> wrote:
> 
> I don't think this is a really hard problem though -- I can think of a few ways to help existing users that probably will work (although I'd want to try them first, to ensure it actually does work, of course). The two I'm thinking of are just doing "git diff" followed by "git apply --directory=llvm" if you just want to save a patch. Or, some "git filter-branch" invocation to rename all the files in your existing repo, followed by "git rebase" (or "git merge"), if you have some more history you want to maintain.

Our clones of LLVM and clang have a reasonable amount of history (a couple of hundred commits, I believe), including multiple branches, that we’d want to preserve.  Both branches have merged from upstream multiple times.  It’s one of the smaller friendly forks that I know about.  I’ve not used git filter-branch before, but I’d be very impressed if there is some simple invocation that can can move from this model.

I was in favour of the GitHub migration primarily because a lot of downstream LLVM users already have a workflow based around GitHub that works well and the proposal was to make this closer to the official workflow.  I’m very nervous about a last-minute change to require everyone downstream to restructure their workflows.

In particular, the fact that we have a third more public GitHub forks of LLVM than of clang, and eight times as many as of lldb implies to me that forcing everyone downstream to pull in all subprojects would not be particularly well received.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3719 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160721/900b3418/attachment.bin>


More information about the llvm-dev mailing list