I just reproduced this one in a live repository. Here's what you do: $ git checkout -b breakme trunk $ vi file1.txt $ git-commit -a -m 'first change' $ vi file2.txt $ git-commit -a -m 'second change' ..... Full moon, become a werewolf ...... C:\svnrepo> edit file2.txt C:\svnrepo> svn commit -m 'this will be gone' ..... Become yourself again .... $ git svn fetch --all # (not sure if this is necessary) $ git svn dcommit $ git log -p The change to file2 by your hairier, fanged self will be gone. The critical thing is that you must dcommit *multiple* commits, and the first one can't be the conflicting file, otherwise it will stop. At the time the first commit of the dcommit has gone through, git-svn now thinks it's all up-to-date. On Sat, Sep 01, 2007 at 12:17:33AM +0100, Johannes Schindelin wrote: > Hi, > > On Fri, 31 Aug 2007, Eric Wong wrote: > > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > > > > harningt just asked about known issues of git-svn on IRC, and I > > > remembered that I had an issue: Accidentally, I forgot to "git svn > > > fetch" before "git svn dcommit"ing, and unfortunately, a colleague had > > > just checked in a change, which got undone by my dcommit. > > > > I believe this was fixed a while back in commit > > 45bf473a7bc2c40c8aea3d34a0eab7a41e77a8ff > > (Thu Nov 9 01:19:37 2006 -0800). > > That is strange, since I had this issue in July or August (this year). > And I am quite certain that I ran with pretty up-to-date git (I usually > track "next" quite closely). > > Ciao, > Dscho > > - > 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 -- Dave Watson Software Engineer MIMvista Corp - 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
