Hello again, resending mail, this time with involved people on CC and with clearer message. I believe there's a bug in git-svn dcommit. If during dcommit someone else commits to svn repository then git a) stops b) loses commits not-yet dcommitted "a" is bug IMO, because it seems to work sometimes (only for first dcommited change?) "b" is more severe, because it destroys user data (in a way) - you have to use reflog to get it back, I believe. I have reproduced it locally - added "sleep" to git-svn in the dcommit loop and did svn commit when it slept. Pasting log from dcommit below. Notes: - local git commits and unfetched svn commits were not conflicting (changed different files) - when starting dcommit there was one unfetched commit (r4) - this worked without problems - new change commited to svn was r8 - during sleep after r6 - "git log remotes/git-svn.." shows nothing => commit history is lost - "git diff" shows all not-yet-commited changes merged in working tree ---------------------------------------------------------------------------------------- piotr@piotr-laptop:/tmp/d/b$ git svn dcommit Committing to file:///tmp/b ... A two.txt Committed r5 M file.txt r4 = 161ef277a311148c42a4391fab1531b818d6b8ba (refs/remotes/git-svn) A two.txt r5 = e2ac55eff258832e0dc7612b9a12913c861897a3 (refs/remotes/git-svn) W: 9a64a0288d5474a78eb528c81efe38a026331fdb and refs/remotes/git-svn differ, using rebase: :100644 100644 b77ce16c276583c177f535cde69e8764ee4a1497 928a139863b65711aa12167b81fefccfacc00d69 M file.txt First, rewinding head to replay your work on top of it... Applying: three.txt Applying: next Applying: next Applying: next Applying: next Sleeping... A three.txt Committed r6 A three.txt r6 = fe11637f550e3158acf333cbd6197fbc775d9000 (refs/remotes/git-svn) No changes between current HEAD and refs/remotes/git-svn Resetting to the latest refs/remotes/git-svn Unstaged changes after reset: M three.txt Sleeping... M three.txt Committed r7 M three.txt r7 = 9ebda9f54668427441daa97b0f152eb1885d266b (refs/remotes/git-svn) No changes between current HEAD and refs/remotes/git-svn Resetting to the latest refs/remotes/git-svn Unstaged changes after reset: M three.txt Sleeping... M three.txt Committed r9 M file.txt r8 = 92bcba5a1a5be41d4393be1810bed0e9417da1a8 (refs/remotes/git-svn) M three.txt r9 = 6988d79c042c21534241e4f6e82ef29056ce69bc (refs/remotes/git-svn) W: cdc341b381aab0ab01233bcc0b47d36acef75eb8 and refs/remotes/git-svn differ, using rebase: :100644 100644 928a139863b65711aa12167b81fefccfacc00d69 a063167d351d2715c1a612cd0f431ac77b9eba92 M file.txt Cannot rebase: You have unstaged changes. Please commit or stash them. rebase refs/remotes/git-svn: command returned error: 1 piotr@piotr-laptop:/tmp/d/b$ git status # On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: three.txt # no changes added to commit (use "git add" and/or "git commit -a") piotr@piotr-laptop:/tmp/d/b$ git log remotes/git-svn.. piotr@piotr-laptop:/tmp/d/b$ git diff diff --git a/three.txt b/three.txt index 7bfc0fd..ce447d2 100644 --- a/three.txt +++ b/three.txt @@ -1,2 +1,5 @@ three next +next +next +next ---------------------------------------------------------------------------------------- I'm also attaching "sleep" patch, logs from creating/commiting to svn repository and from git svn clone for convenience (some messages from svn are in Polish but that shouldn't matter) git version 1.7.5-rc1 On Mon, Apr 11, 2011 at 4:32 PM, Piotr Krukowiecki wrote: > Hi, > > I've done some changes to "local" trunk, dcomitted them to svn server, > then cherry-picked those changes to "local" branch and tried to > dcommit them to svn. > Several changes where successfully dcommited, but then I got an error. > > Two problems: > 1. after the error I'm left with changes not sent to svn server as > unstaged changes > 2. git-svn errors if someone commits something to svn during my commit > even if there is no conflict > > Even if the second problem is intentional (which I'm not sure is a > good idea), the first problem means it's not possible to continue > after the error (which is not really an error but should be a warning, > even if it stops the dcommit). > > > Full story: > > The log looked like this: > > [... this is the end of older commit, which succeeded ...] > W: -empty_dir: cptests/branches/a_branch/src/file > r23939 = 400e84221ca15be3976ba4dcd6d7a2eb1464b00e (refs/remotes/a_branch) > No changes between current HEAD and refs/remotes/a_branch > Resetting to the latest refs/remotes/a_branch > Unstaged changes after reset: > M       src/file > [... next commit preparation and commit ...] >        R       src/file > Committed r23941 >        M       etc/file.xml > r23940 = 420c7b2c8f155563a4f4c8e5421857846bf3ebe5 (refs/remotes/a_branch) >        D       src/file > [...] > r23941 = 010c5b3883c473dd236de1a146fad1e90bd323fd (refs/remotes/a_branch) > W: bfb909cb21e26930364331660460ccd7be355a2e and refs/remotes/a_branch > differ, using rebase: > :040000 040000 5df0982b1cf277dd7d915d32a9ff145554fb9c94 > a662095f06bd349c1a458d52697561ba9d005bac M      etc > Cannot rebase: You have unstaged changes. > Please commit or stash them. > rebase refs/remotes/a_branch: command returned error: 1 > > Now I was left with all the remaining changes "squashed" - git status > showed a list of unstaged changes. So all changes not yet commited > were in fact lost as commits and left in the working tree as one bit > not-yet-added change. > > I believe the reason for this was that while I was dcommiting my > changes someone changed the "etc/file.xml" > > So my previous dcommit was r23939 (src/*). Then someone else checked > into svn r23940 (etc/file.xml). Then (or earlier) git svn dcommited > r23941 (src/*). After that dcommit stopped with error. > > > In this case I have just reset --hard and cherry-picked changes that > were not commited, and it worked this time, but I wonder what should I > do next time. > What if those are not cherry-picked changes, but normal changes? Will > I have to use reflog to get back in time? > > Also, I think in this case svn might continue with dcommit. It already > commited one revision after the other-person commit. The other commit > changed a completely different directory. > > Even if this is left as error, it should be possible to continue > dcommit in an easy way. Not-commited changes should not be deleted and > left as unstaged changes. > > Also, the "you have unstaged changes" error is not very helpful. I > thought it meant it commited a change partially, or maybe some other > weird thing happened. > > > Thanks, > > -- > Piotr Krukowiecki > -- Piotr Krukowiecki