tags:

views:

290

answers:

1

I'm reading about using git as an svn client here:

http://learn.github.com/p/git-svn.html

That page suggests that you do git svn rebase before git svn dcommit, which makes perfect sense; it's like doing svn update before doing svn commit. Then, I started looking at the documentation for git svn dcommit (I was wondering what the 'd' is about):

http://www.kernel.org/pub/software/scm/git/docs/git-svn.html

You have to scroll down a bit to see the documentation on dcommit, which says this:

Commit each diff from a specified head directly to the SVN repository, and then rebase or reset (depending on whether or not there is a diff between SVN and head).

This confuses me, because if you do as the first page says, there will be no changes to pull down from svn once the first part of dcommit finishes.

I'm also confused by the part that talks about reset; isn't git reset for removing changes from the staging area?

Why would rebase or reset follow (the first part of) a dcommit?

+2  A: 
MikeSep
re git svn rebase not required before "committing": by committing, you mean git svn dcommit right?Separately, do you mean that nothing will get confused later if I push changes from my local git to the remote svn using git svn dcommit assuming I haven't touched any files that have changed in svn since my last git svn rebase?I'm also confused about a number of things in your second paragraph. 1) Is there any point in reimporting? 2) Are you saying you've inferred this from the contents of the commit messages?
allyourcode
3) What do you mean by "git-svn can reset to the fetched-from-svn content"? I thought git reset is used to remove changes from the staging area; whereas, you seem to be saying that reset changes which revision the current branch points to. 4) How could any changes not be pushed to svn after doing git svn dcommit? Doesn't that command push all changes from my local git repo to the remote svn repo??
allyourcode
MikeSep
Re #3: `git reset` works differently depending on which form you use. `git reset HEAD foo.txt` unstages changes to foo from the index. `git reset [--soft|--mixed|--hard|...] <commit>` moves your branch and changes the index/workarea depending on which switch you give.
MikeSep
Re #4: I don't think this happens often, so I didn't mean to imply as such. You can give an argument to `git svn dcommit` ("An optional revision or branch argument may be specified, and causes git svn to do all work on that revision/branch instead of HEAD."), but I've never used this myself.
MikeSep
Thanks for clarifying, Mike. I think I get it now. The reason for rebase (or reset) after dcommit is because dcommit pulls down new revisions (including the ones that were just created earlier in the dcommit process) after adding commits to the (remote) svn repo. You'll want those commits to be on the master branch, which is what rebase or reset does. As long as the remote svn repo didn't get ahead of you (e.g. you always do git svn rebase before git svn dcommit), then it will always do reset after dcommit; otherwise, rebase might be necessary.
allyourcode
I guess a rebase would add changes that keep the source tree the same as before doing git svn dcommit. In that case, if you were to dcommit again, you would clobber your teammate's work, right?
allyourcode
I'm not entirely sure of the scenario you're describing. You certainly can't clobber work that's already been committed to svn, due to its strictly linear history model.
MikeSep