15

I'm working on a project that uses subversion for their repository. Because I need to make some changes that can't be sent to the svn server yet, I started using git svn so that I could do local checkins. My setup looks like this:

Branches: trunk (tracking svn trunk), master (pretty close to what's in svn), and topic.

*------------------ trunk
 \
  *-----------*--------- master
               \
                *-------- topic

Workflow:

[on branch master]
$ git svn fetch
$ git svn rebase
$ git checkout -b topic
$ git rebase master
[hack hack hack]
$ git commit -a
[once upstream is ready for my changes]
$ git svn fetch
$ git checkout master
$ git svn rebase
$ git checkout topic
$ git rebase master
$ git svn dcommit
$ git checkout master
$ git svn rebase
$ git branch -d topic

Presuming that no one commits to svn between git svn fetch and git svn rebase, Is git svn rebase run on master basically the same as git rebase trunk run on master?

Is there a more sensible workflow to use? It seems like there's a lot of changing branches and rebasing going on. I understand that I want to be able to rebase my work on top of whatever's in svn, but it seems like I'm doing more rebases than are strictly necessary.

Sean McMillan
  • 10,058
  • 6
  • 55
  • 65

1 Answers1

19

Note, from git svn, as detailed in "Why is the meaning of “ours” and “theirs” reversed with git-svn":

git svn rebase

This fetches revisions from the SVN parent of the current HEAD and rebases the current (uncommitted to SVN) work against it.

So you don't need the git svn fetch before your git checkout master and git svn rebase, especially if you track only trunk (parent of master).

Second point, the git svn dcommit would create revisions in SVN for each new commit on master, but your workflow doesn't show any new commit on master, only on topic (which isn't ever merged on master)

The OP Sean McMillan comments:

According to the docs, git svn dcommit without a branch specified pushes the commits on the current HEAD, not just on master. So I commit to SVN from my branch, then rely on a git svn rebase on master to bring the commits back from SVN. I abandon the topic branch after I've dcommited. Is this not kosher?

He details that:

I can't sent them to SVN... yet. Upstream wants to "freeze" the trunk for a release, meanwhile, I'm working on functionality for the next release.

But the ultimate question is, "is git rebase trunk master the same as git svn rebase on the master branch?" If it is, then I don't need to be constantly changing my branches, just to rebase my master branch against SVN. But if it's not, and there's some kind of magic happening when I git svn rebase, I want to know.

To which I reply:

A git svn fetch followed by a git rebase trunk master would be the equivalent of a git svn rebase.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • On the first: So I don't need to `git svn fetch` before I `git svn rebase`... As long as I'm on `master`. But if I'm on `topic`, `git svn fetch` will update `trunk`, but leave `master` and `topic` alone. I never `git svn rebase` my topic branch though, I only `git rebase` it. Interesting to know. – Sean McMillan May 18 '12 at 13:01
  • @SeanMcMillan "As long as I'm on master": yes, that is the idea. And you do a `git checkout master` every time, so... – VonC May 18 '12 at 13:03
  • On the second: According to the docs, `git svn dcommit` without a branch specified pushes the commits on the current HEAD, not just on `master`. So I commit to SVN *from my branch*, then rely on a `git svn rebase` on `master` to bring the commits back from SVN. I abandon the `topic` branch after I've dcommited. Is this not kosher? – Sean McMillan May 18 '12 at 13:04
  • @SeanMcMillan I am not sure why you would `dcommit` while being on topic, since one premiss of your question is that you "need to make some changes that can't be sent to the svn server". That is why I questioned the use of `dcommit`. – VonC May 18 '12 at 13:06
  • But the ultimate question is, "is `git rebase trunk master` the same as `git svn rebase` on the master branch?" If it is, then I don't need to be constantly changing my branches, just to rebase my master branch against SVN. But if it's not, and there's some kind of magic happening when I `git svn rebase`, I want to know. – Sean McMillan May 18 '12 at 13:08
  • Ah.. I can't sent them to SVN... yet. Upstream wants to "freeze" the trunk for a release, meanwhile, I'm working on functionality for the *next* release. – Sean McMillan May 18 '12 at 13:10
  • "is git rebase trunk master the same as git svn rebase on the master branch?": no, the first is a pure git history rewrite of `master` on top of an unchanged `trunk` branch. The second will update `trunk` first. – VonC May 18 '12 at 13:12
  • I must not be communicating well today. Presuming that my `git svn fetch` has updated trunk, and that no one has committed to trunk since then, is the outcome the same? What primitive operations does `git svn` do when you `git svn rebase`? – Sean McMillan May 18 '12 at 13:18
  • @SeanMcMillan yes, sorry: a `git svn fetch` followed by a `git rebase trunk master` would be the equivalent of a `git svn rebase`. – VonC May 18 '12 at 13:39
  • That's what i suspected, but I wanted to confirm it. Please edit that into your answer. :-) Feel free to tweak the question to make it more clear too. – Sean McMillan May 18 '12 at 13:58
  • @SeanMcMillan answer edited, with the relevant part of the comments included, for more visibility. – VonC May 18 '12 at 14:20