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

[Justin Lebar via Phabricator via llvm-commits]

jlebar added a comment.

Thanks a lot for proofreading my totally untested code.  :)

In https://reviews.llvm.org/D53414#1271639, @mehdi_amini wrote:

> I feel adding more stuff here will be a bit confusing moving forward.


I agree, but my goal is to avoid bikesheding on this as much as possible, and I'm sort of afraid as soon as I create a new page I'm going to get to enjoy that...  At some point someone is going to have to write the canonical documentation, and they can move this there.  And until that canonical documentation exists, does it hurt too much to have this here?



================
Comment at: llvm/docs/Proposals/GitHubMove.rst:874-875
+  # my-branch that are not in origin/master.
+  $ diff <(git log --pretty=%H --merges origin/master | sort) \
+         <(git log --pretty=%H --merges my-branch | sort) | grep '^>'
+
----------------
fedor.sergeev wrote:
> this can be done shorter and faster:
> git log --oneline --merges origin/master..mybranch
Hm...I *think* you're right.  I was worried about weird edge cases, but I now I can't articulate any.  Done, thanks.


================
Comment at: llvm/docs/Proposals/GitHubMove.rst:906
+  $ git checkout -b my-branch <new-base-commit>
+  $ git am /tmp/my-branch-patches/*
+
----------------
fedor.sergeev wrote:
> fedor.sergeev wrote:
> > Why not rebase --onto instead of format-patch/am ?
> > Never used git-am for a bulk set of patches but my feeling is that rebase would be a bit more "controllable" in a case when something wrong happens with the patches...
> > (also it has a benifit of not requiring to put patches somewhere into /tmp :) )
> Ignore the above, it wont work with --directory=llvm hacks.
These steps have two separate repositories; git rebase only operates within one repository.

I did it this way because if I suggested that pulling both histories into one repository was a good way to do it, people would complain that they can't switch to the new monorepo without making their .git directory larger.  :)


================
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>
----------------
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.


https://reviews.llvm.org/D53414