Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
quoted text
> 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?

The latter option is much simpler.  I actually thought there was already
a check in dcommit that prevents it from committing with a dirty index,
but apparently not...

quoted text
> 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.

Oops, sorry.  I've been busy and forgetful.  I'll try to work on it
later tonight or tomorrow.

-- 
Eric Wong
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html