Thanks! Seemed weird at first that I would see both the original commit and the merge. I'm realizing now that this is the way Git handles merges, however, so I guess it's just trying to apply the same logic during the svn 2 git migration by utilizing the svn:merge-info to "re-create" the branch history. I noticed that this did not happen in branches created before we upgraded to the SVN version that supported merge tracking. On Mon, Jul 12, 2010 at 2:24 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Hi Bradley, > > Bradley Wagner wrote: >> On Thu, Jul 8, 2010 at 10:58 PM, Bradley Wagner wrote: > >>> I've done a migration using "git-svn init" and "git-svn fetch". After >>> the migration, I did a "git log refs/remotes/svn/6.7" and found that >>> it listed both the commits that I merged into the 6.7 branch and the >>> original commits to the trunk/master even though the SVN history >>> obviously only has what was merged into that branch. > > Yes, this is intentional. If you try ‘gitk --all’, you can see > the history of all branches, where they branched from, and so on. > > As far as I know the svn:mergeinfo is not actually used until > a merge. Instead, git-svn uses subversion’s file copy tracking > information to follow history past a branch point; see the > find_parent_branch function in the git-svn script for details. > > Hope that helps, > Jonathan > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html