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

[Fedor Sergeev via Phabricator via llvm-commits]

fedor.sergeev added inline comments.


================
Comment at: llvm/docs/Proposals/GitHubMove.rst:934-935
+  $ git log -n1 --pretty="%aD %at" $(git merge-base origin/master my-branch)
+  $ git log -n1 --since <date from old-base-commit> \
+      --author <author from old-base-commit>
+  $ git merge <new-base-commit>
----------------
danilaml wrote:
> fedor.sergeev wrote:
> > fedor.sergeev wrote:
> > > danilaml wrote:
> > > > jlebar wrote:
> > > > > fedor.sergeev wrote:
> > > > > > I'm afraid this wont work. --since sets a bottom limit for the commits shown with git-log, but git-log starts from the top (HEAD), so in most cases it will be equivalent to git log -n1 --author <xxx>, which is absolutely not whats needed here.
> > > > > > 
> > > > > > Perhaps doing both --since/--until can do the trick. And if we find the times of commits reliable enough then we can automate it:
> > > > > > 
> > > > > > merge_base=$(git merge-base origin/master my-branch)
> > > > > > merge_time=$(git log -n1 --pretty=%at $merge_base)
> > > > > > merge_author=$(git log -n1 --pretty="%an <%ae>" $merge_base)
> > > > > > git log -n1 --since="@$merge-time" --until="@$merge_time" --author="$merge_author"
> > > > > Added --until.  I decided not to script it because this is not 100% sound, and so I'd rather encourage a human to be in the loop.
> > > > How would that deal with multiple merges (not necessarily only with origin/master) with many conflicts? Would that essentially require to manually redo all merges?
> > > Then you still need to add %an <%ae> to the merge-base description format, e.g.:
> > >   git log -n1 --pretty="format:Date-Time: %aD %at%nAuthor: %an <%ae>%nDescription:%s" $(git merge-base origin/master my-branch)
> > > so users have something to copy-paste from.
> > > How would that deal with multiple merges (not necessarily only with origin/master) 
> > This is not trying to recreate all the merges.
> > It just a single *additional* merge (done right below this thread of comments).
> > This merge will essentially join two disjoint histories (having a lot of duplication there for all the upstream
> > commits that happened to be in your own monorepo).
> > 
> > Recreating merges without duplicating upstream commits requires substantial complications in history rewrite ala git filter-branch and are not for the faint of heart...
> Ah, I think I understand. So it's basically nothing more than "find the commit in new final repo corresponding to the latest merged commit from some other llvm git mirror and merge with that"? I.e. if you know you are at HEAD you could just do the merge?
> 
> Then I don't see this that much helpful, since IMHO, the main problem comes from the actual transition to the new repo and everything it involves, not finding the point of such transition. I.e. stuff like rewriting history to use final repo commits instead (in if you don't lieve with duplicated commits), or dealing with the merge conflicts again and again (since I don't think that git would understand that they were already resolved by previous non-final merge). The painful stuff.
> it's basically nothing more than "find the commit in new final repo"
Exactly.

> the main problem comes from the actual transition to the new repo and everything it involves, not finding the point of such transition
It depends on what do you want to achieve. If you do not care about past history other than being able to find your own downstream commits then doing a single merge should be fine.

> rewriting history to use final repo commits instead 
Yes, rewrites are considerably more complicated.

> dealing with the merge conflicts again and again
And here - no, you will not need to perform *any* merge conflict resolution besides the first one described here,
which is, btw, very likely to succeed without conflicts unless you were doing something really weird with your merges. As soon as you are done with the merge, all the commits that go up from the merge point (either upstream or downstream) will conflict only on their contents, not on something that happened before the merge point.



https://reviews.llvm.org/D53414