{"thread":{"id":"10707","subject":"git svn dcommit with a dirty index","startedAt":"2007-11-07T19:06:49Z","lastAt":"2007-11-11T01:42:52Z","messageCount":2,"participants":["Benoit Sigoure","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"58709","messageId":"DBC1E504-9007-4C89-9728-2DDBAFF2053B@lrde.epita.fr","threadId":"10707","inReplyTo":null,"subject":"git svn dcommit with a dirty index","fromName":"Benoit Sigoure","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-11-07T19:06:49Z","receivedAt":"2007-11-07T19:06:49Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"Hello list,\n From what I understand, when using dcommit, git-svn uses rebase to  \n\"sync\" the history with what has just been committed.  If the index  \nis in a dirty state, this will cause trouble.  I thought about using  \ngit-stash and then git stash apply --index but I'm afraid this could  \nbe confusing if dcommit actually brings more revision in that the  \nones it has just committed.  I'm not sure this is possible and even  \nif it is, it might not be troublesome since if the commits are  \naccepted in the SVN repo, they surely don't overlap with commits that  \nhave been sent in the mean time.  But it's risky, so I don't know  \nwhat to do.  If we use the stash approach, we might want to tell the  \nuser that we bailed out because of a problem that needs to be fixed  \nand that he can recover his changes with git stash apply --index.\n\nOr we should simply check that the index isn't dirty beforehand and  \nrefuse to dcommit if it is.\n\nAny suggestion?\n\nPS OT: Eric, have you made any progress on the svn:externals<- \n >submodules mapping?  I badly need this feature, but I don't want to  \nstart to work on it if you're currently working on it (or about to  \ndeal with it) to avoid unecessary effort duplication.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"59256","messageId":"20071111014252.GA18748@mayonaise","threadId":"10707","inReplyTo":"DBC1E504-9007-4C89-9728-2DDBAFF2053B@lrde.epita.fr","subject":"Re: git svn dcommit with a dirty index","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-11-11T01:42:52Z","receivedAt":"2007-11-11T01:42:52Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Benoit Sigoure <tsuna@lrde.epita.fr> wrote:\n> Hello list,\n> From what I understand, when using dcommit, git-svn uses rebase to  \n> \"sync\" the history with what has just been committed.  If the index  \n> is in a dirty state, this will cause trouble.  I thought about using  \n> git-stash and then git stash apply --index but I'm afraid this could  \n> be confusing if dcommit actually brings more revision in that the  \n> ones it has just committed.  I'm not sure this is possible and even  \n> if it is, it might not be troublesome since if the commits are  \n> accepted in the SVN repo, they surely don't overlap with commits that  \n> have been sent in the mean time.  But it's risky, so I don't know  \n> what to do.  If we use the stash approach, we might want to tell the  \n> user that we bailed out because of a problem that needs to be fixed  \n> and that he can recover his changes with git stash apply --index.\n> \n> Or we should simply check that the index isn't dirty beforehand and  \n> refuse to dcommit if it is.\n> \n> Any suggestion?\n\nThe latter option is much simpler.  I actually thought there was already\na check in dcommit that prevents it from committing with a dirty index,\nbut apparently not...\n\n> PS OT: Eric, have you made any progress on the svn:externals<- \n> >submodules mapping?  I badly need this feature, but I don't want to  \n> start to work on it if you're currently working on it (or about to  \n> deal with it) to avoid unecessary effort duplication.\n\nOops, sorry.  I've been busy and forgetful.  I'll try to work on it\nlater tonight or tomorrow.\n\n-- \nEric Wong\n"}]}