Re: git svn dcommit with a dirty index

From: Eric Wong <normalperson@yhbt.net>
Date: Nov 11, 2007, 01:42 UTC
Message-ID: <20071111014252.GA18748@mayonaise>
In-Reply-To: <DBC1E504-9007-4C89-9728-2DDBAFF2053B@lrde.epita.fr>

Benoit Sigoure <tsuna@lrde.epita.fr> wrote:

Show 18 quoted lines

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

> 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