[PATCH] D53414: Add instructions for migrating branches from one git repository to another.

[David Greene via Phabricator via llvm-commits]

greened added inline comments.


================
Comment at: llvm/docs/Proposals/GitHubMove.rst:938
+
+Multirepo to Monorepo, With Merges
+----------------------------------
----------------
jyknight wrote:
> bogner wrote:
> > greened wrote:
> > > fedor.sergeev wrote:
> > > > jlebar wrote:
> > > > > greened wrote:
> > > > > > bogner wrote:
> > > > > > > I expect this is the common case for anyone with any significant out of tree changes. We probably need to pay a bit more attention to it.
> > > > > > Agreed.  It is definitely the situation for us.  I suspect the vast majority of cases will be people using the existing project repositories, with their own long-lived branches that have periodic merges from master.  Essentially, downstream looks like a "downstream master" branches that periodically merge from the "upstream master" branches to sync up.
> > > > > > 
> > > > > > In our situation we have multiple such "downstream master" branches, one for each project repository we're using (llvm, compiler-rt, etc.).  It's not at all clear to me how we will transition those multiple branches to a single "downstream master" branch on the monorepo.
> > > > > > 
> > > > > > In the worst case we'll replay all of our downstream commits on top of the monorepo master, but I am hoping there is a better way.
> > > > > I hear that you and others are in this position.
> > > > > 
> > > > > Do you want to rewrite history so it's like you always had a monorepo?  That's tantamount to "replaying all of our downstream commits on top of the monorepo master".  It's going to be painful, but it sounds like you have a rough idea of how to do it?  I'm not sure what a better way would be, in part because I'm not sure what you're trying to accomplish.
> > > > > 
> > > > > Anyway writing such a tool was not what I meant to volunteer for when I volunteered to write this patch.  Do you want me to abandon it?
> > > > I believe this patch is still very useful, as it at least enumerates the options if not providing full solutions.
> > > > Writing a generic automated tool for the most complicated case is a very challenging task, and inability to solve it should not stop us from providing the best guidance we can.
> > > > 
> > > I have to experiment a bit, but it's possible that some unpushed changes to git-subtree that I have might help.  If that turns out to be the case, I'd make it a high priority to make those changes available (probably as a fork on GitHub) and we could point people there if they want to try it.
> > > 
> > > I know that writing such tools is difficult.  I did something similar in git-subtree and it took a very long time to get everything working.
> > > 
> > > The document is certainly useful.  You shouldn't abandon it!
> > I've sent some thoughts about an approach that makes this a lot easier to deal with to llvmdev. See http://lists.llvm.org/pipermail/llvm-dev/2018-October/127334.html
> Can now also suggest the migrate-downstream-fork.py tool I wrote about on the list. (Could just point to the mailing list archive initially, before adding better instructions).
Yes, we should absolutely mention migrate-downstream-fork.py.  It worked great for our downstream forks.  Here's the link to James' post about it:

http://lists.llvm.org/pipermail/llvm-dev/2018-November/127496.html

I also added a tool to zip downstream forks based on a submodule update history:

http://lists.llvm.org/pipermail/llvm-dev/2018-November/127704.html

I think both of these tools will be useful for folks living downstream.


https://reviews.llvm.org/D53414