Benoit Sigoure <tsuna@xxxxxxxxxxxxx> wrote: > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
