`git svn rebase` vs `git rebase trunk`

Question

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

Answer 1

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.