Chris Stankevitz ( 9月25日（火）) >>
> Please consider the attached steps which create an SVN repo and setup git
> to track it.
> 1. Why do "local-newbranch" and "master" not share a common ancestor?
I think the reason is that the method you've used to add the branch to
git-svn treats that branch as a separate remote repository. git-svn
doesn't realise it should be treating it as a branch and so doesn't try
and trace back beyond the first commit to that branch to find the
> 2. How do I make them share a common ancestor?
Add the svn branches directory to the branches parameter for the
existing "svn" remote, rather than adding a new remote. The recommended
way of doing this is to pass --branches or --stdlayout on clone/init,
but if this is impossible, you could try modifying your sequence of
-- >8 --
--- a/steps.txt 2012-09-26 12:09:33.331806620 +0900
+++ b/steps.txt 2012-09-26 12:08:34.383604192 +0900
@@ -23,9 +23,9 @@
# Update the GIT repo to follow the SVN branch
-git config --add svn-remote.newbranch.url
-git config --add svn-remote.newbranch.fetch :refs/remotes/newbranch
-git svn fetch newbranch
+git config --add svn-remote.svn.branches "branches/*:refs/remotes/*"
+git svn fetch
git checkout -b local-newbranch -t newbranch
git svn rebase newbranch
-- 8< --
Note the removal of the ".git/svn/.metadata" file. When I tried it
without doing that, git-svn didn't notice the new branch settings and
didn't try to fetch the branches. deleting this file forces git-svn to
regenerate it with the latest settings.
> 3. Assuming (2) is possible, will I be able to rebase "master" changes onto
You need to be careful about this, as you can't rewrite history on the
svn side. Essentially svn has no "rebase", only "merge".
What this means is you can use all the git functionality on local
branches, as far back as the last svn commit. As soon as you reach
something that has been committed to svn, though, you have to limit
yourself to svn functionality.
Taking your example, here is the state at the end of steps.txt (with the
patch above applied). I will mark svn branches in caps, and git
branches in lower-case.
--A--B TRUNK, master
-C NEWBRANCH, local-newbranch
Say you work on local-newbranch, and other people work on the trunk.
If you do "git svn pull" on master the graph might look like this
(commits which have been committed to SVN in caps, those which only
exist in your local git repo in lower case):
In this case, commits D and E only exist in git, but everything else has
already been committed to svn. If you want to have access to commits
F-H on the local-newbranch branch, you will need to do it the svn way;
ie by creating a merge commit on NEWBRANCH which pulls in those changes.
You can do that by passing the --squash option to "git merge", thus:-
$ git checkout local-newbranch
$ git merge --squash trunk
Here M is a single commit containing all of the changes held in commits
F-H. Subversion doesn't support the git concept of "multiple parent
commits", so you lose that element of merge history on the graph. The
merge is marked as having taken place after D and E were written in the
history. Since you said you wanted to rebase, perhaps that isn't what
you want; you might want the merge to have been performed before your
changes. You can accomplish that, provided you haven't dcommitted
$ git checkout -b newbranch-merge newbranch
$ git merge --squash trunk
$ git rebase newbranch-merge local-newbranch
$ git branch -D newbranch-merge
Since newbranch-merge hadn't been committed to svn yet, the rebase was
possible and the merge will go down in history as having happened before
the changes on local-newbranch.
> 4. Assuming (3) is possible, will I be able to dcommit "local-newbranch"?
Running a "git svn dcommit" while "local-newbranch" is checked out
should update the newbranch branch on the SVN side, and running it on
"master" should update "trunk".
I would only recommend doing all this if you need to share these
branches with other users of svn, though. Since branching is so easy
and natural in git, people tend to find themselves making a lot of
local, short-lived branches to do their work on -- I have about eight
running currently. These are all local to my git repo and I'll delete
them once the work on them is done. Doing this allows me to rebase
branches on top of other branches, move things around, and modify them
until they are pristine, at which point I merge them into master and
dcommit them to the server.
> Thank you,
Hope that helped, and wasn't too long and rambly!
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at