0

I've set up a process, based on Adam Spiers' answer in a previous SO thread, to periodically publish a Git repository to a path in an SVN repository. Everything is working quite well, but there's one piece I haven't figured out. When I'm grabbing subsequent Git changes using cherry-pick, how do I figure out which new changes have occurred on this Git side, needing to be cherry-picked into the SVN side?

To be more specific, after I do the initial push of the Git history into SVN, I'm now sitting on a master branch which has the same content & patch history as the Git origin, but it's diverged from origin/master for basically its full history:

% git --no-pager diff master git-svn
% git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 3 and 2 different commit(s) each, respectively.
#
nothing to commit (working directory clean)

Now, I do a fetch of new upstream changes:

% git fetch
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /cygdrive/c/foo/git/testrep
   6d7dd94..08d3d19  master     -> origin/master

At this point, I need to figure out which revisions need to be cherry-picked, then I'll cherry-pick them and do a git svn dcommit. But I can't figure out how to get that list of cherries. I've tried various git cherry commands, and both git cherry origin master and git cherry master origin report long lists of basically every change on each side.

Should I resort to parsing the last cherry-pick out of the log file? I'm using git cherry-pick -x, so I do have a record there.

Community
  • 1
  • 1
Ken Williams
  • 22,756
  • 10
  • 85
  • 147
  • Have you tried a simple `rebase --onto`? Git should be clever enough to figure out patch-equivalent commits and drop everything that was already picked for your SVN branch. – knittl Oct 30 '12 at 21:24
  • I'm not seeing it work - if I do `git fetch origin` and then `git rebase --onto git-svn origin`, nothing seems to happen, when I'd expect to see 2 new commits rebased. Also, would that approach get unwieldy if I have hundreds/thousands of commits? – Ken Williams Oct 30 '12 at 22:08
  • Try something along the lines of `git rebase --onto git-svn `. Maybe combine with `-i/--interactive` – knittl Oct 31 '12 at 06:50
  • It would help HUGELY if you could provide a reduced test case. – Adam Spiers Oct 31 '12 at 09:49
  • @Adam, do you mean an actual repo to look at? I think all the steps I've performed are here and in the previous thread. – Ken Williams Oct 31 '12 at 13:54
  • I mean all the steps starting from zero repos through to reproducing the problem. You never gave details of how the merge commits are created, for instance. – Adam Spiers Oct 31 '12 at 20:42

1 Answers1

0

So I think I have a solution - after every git cherry-pick ... git svn dcommit round, I do a git tag -f last-picked origin. Then next time, I can cherry pick from last-picked to origin.

I'm willing to mark someone's answer as accepted if they have a better solution, but at this point it looks like I don't necessarily need another answer.

Ken Williams
  • 22,756
  • 10
  • 85
  • 147