Git-svn非樱桃

Question

Given a repository that was previously in SVN and has now been fully converted to Git (ie. currently accessed via "pure" git and not git svn ):

Given a mainline branch and a release branch that diverged from mainline prior to the Git conversion:

Is there any easy way (from Git) to tell which commits are present on the release branch and not on the mainline branch (ie. possible candidates to be cherry-picked back to mainline, when a fix has been made directly to the release branch)?

The problem I see is that commands like git cherry (which is apparently the right choice for branches that diverged after the Git conversion) expect that complete commits are kept intact, but merges made in SVN prior to the conversion tend to be roll-ups -- basically squashed cherries instead of intact cherries.

In SVN, this is accomplished by inspecting the svn:mergeinfo property (usually automatically via tools). I don't know if this information was preserved during the conversion process, or if there are any tools that know to look for it in an apparently-native-Git repository.

Answer 1

You can get a list of commits whose changes are present in the release branch but not on master – and are therefore candidates for cherry picking – by using git log --cherry-pick and the triple-dot syntax :

git log --cherry-pick --right-only master...release

Let's break it down:

• master...release selects the commits that are reachable from release but not master and vice versa.
• --right-only shows only the commits reachable from the right side of the range, in this case the release branch
• --cherry-pick hides the commits from release whose changes have already been applied to master – ie they're considered patch equivalent .

The key part here is --cherry-pick because that's what causes Git to determine whether a commit has been applied to a branch based on the commit's patch and not its SHA-1 hash.