Hello list,
 From what I understand, when using dcommit, git-svn uses rebase to  
"sync" the history with what has just been committed.  If the index  
is in a dirty state, this will cause trouble.  I thought about using  
git-stash and then git stash apply --index but I'm afraid this could  
be confusing if dcommit actually brings more revision in that the  
ones it has just committed.  I'm not sure this is possible and even  
if it is, it might not be troublesome since if the commits are  
accepted in the SVN repo, they surely don't overlap with commits that  
have been sent in the mean time.  But it's risky, so I don't know  
what to do.  If we use the stash approach, we might want to tell the  
user that we bailed out because of a problem that needs to be fixed  
and that he can recover his changes with git stash apply --index.

Or we should simply check that the index isn't dirty beforehand and  
refuse to dcommit if it is.

Any suggestion?

PS OT: Eric, have you made any progress on the svn:externals<- 
 >submodules mapping?  I badly need this feature, but I don't want to  
start to work on it if you're currently working on it (or about to  
deal with it) to avoid unecessary effort duplication.

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory