git-svn problem with git add --patch resulting in conflicts

Question

Basically when i want to commit two separate changes in the same file that resulted from an git add --patch <file> operation, git svn rebase later on throws 1-2 conflicts upon comitting the second change when using git add for the second change.

so i'm basically doing this (i'm on master branch and have fetched the svn repository):

git checkout -b feature
... make two unrelated changes to file test.txt...
git add --patch test.txt
... add first change but ignore second one
git commit -m "change1"
git stash
git checkout master
git merge feature
git svn rebase
git svn dcommit
git checkout feature
git stash apply

now here there's two ways to do it, first the one that works:

git add --patch test.txt
... select everything (which is the second change in this case)
git commit -m "change 2"
git checkout master
git merge feature
git svn rebase
git svn dcommit

here's the one that doesn't work:

git add test.txt #notice there's no --patch
git commit -m "change 2"
git checkout master
git merge feature
git svn rebase #yields a conflict

So why is it that when using git add --patch for the second change, I can commit to the svn repository without problems, but when just using git add for the second change, it results in a conflict? I'm quite new to git, so this might be a stupid question, but as I see it, both commandsets should do exactly the same.

Answer 1

why are you creating a branch for your 2 commits and then merge back? i guess this could give problems, since merges in git work differently from how they work in svn.

this should work ("should", but i'm pretty sure it does):

# on master, no need to create a branch
$ git add -p file
$ git commit -m "first set of changes"
$ git add file
$ git commit -m "the remaining changes"
# apply your commit on top of eventually new changes upstream
$ git svn rebase
# commit your 2 commits to svn
$ git svn dcommit

---

in svn branches are just copies of a directory (most often the trunk directory), and merge commits do not differ from normal commits (except the new svn:mergeinfo property starting with svn 1.6)

commits in git are different, each commit stores a link to it's parent commit. svn does not need this, as it can simply use REV-1. merge commits in git thus have multiple parents (the merging branch and the merged branch)

i do not know what happens if you dcommit a git to svn, but it will probably only commit the merge commit itself, without history (message being something like "merged branch 'bla' into 'master').

when you run svn commit only your new changes are sent to the server to save bandwidth. now, merges in git work different and the difference to previous versions will probably not be what you expect it to be, that's why git svn dcommit fails.

it even says so in the git svn documentation: do not merge branches using git and dcommit them to svn, it will most likely mess up your history

Running git merge or git pull is NOT recommended on a branch you plan to dcommit from. Subversion does not represent merges in any reasonable or useful fashion; so users using Subversion cannot see any merges you've made. Furthermore, if you merge or pull from a git branch that is a mirror of an SVN branch, dcommit may commit to the wrong branch. git svn docs