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

Tue Nov 6 14:28:14 PST 2018

jyknight added a comment.

Let's submit this soon, even if it will be further edited.

================
Comment at: llvm/docs/Proposals/GitHubMove.rst:881
+  # Check that the set of commits in your branch looks right.
+  git log $(git merge-base origin/master my-branch)..my-branch
+
----------------
Don't think you need merge-base here. `git log origin/master..my-branch` should be sufficient?

================
Comment at: llvm/docs/Proposals/GitHubMove.rst:883-885
+  # Looks good, let's export a patch for each of the commits!
+  $ git format-patch -o /tmp/my-branch-patches \
+    $(git merge-base origin/master my-branch)..my-branch
----------------
I found it easier to output to a single file, using `git format-patch --stdout origin/master..my-branch > foo.patch`. (but that doesn't really matter, maybe not worth mentioning)

================
Comment at: llvm/docs/Proposals/GitHubMove.rst:860-861
+Suppose you have been developing against an LLVM git repository -- either the
+multirepo or one of the existing monorepos.  You have one or more git branches
+that you want to migrate to the "final monorepo".
+
----------------
Probably worth explicitly mentioning that this is intended for when you're OK with changing your commit hashes as part of the migration.

================
Comment at: llvm/docs/Proposals/GitHubMove.rst:886-889
+  # Make a note of the commit metadata of the merge-base, i.e. the newest
+  # common ancestor between your branch and origin/master.  Call this commit
+  # <old-base-commit>.
+  $ git log -n1 --pretty="%aD %at" $(git merge-base origin/master my-branch)
----------------
Easier to just go by svn revision number of the upstream commit, probably? 

I'd just go directly:

`git checkout -b my-branch 'origin/master^{/llvm-svn=1234\W}'` (\W, aka end-of-word, is only necessary if your revision number is fewer digits than current.)

================
Comment at: llvm/docs/Proposals/GitHubMove.rst:938
+
+Multirepo to Monorepo, With Merges
+----------------------------------
----------------
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).

https://reviews.llvm.org/D53414