{"thread":{"id":"26198","subject":"\"git svn fetch\" on a branch is broken after \"git svn reset\"","startedAt":"2011-01-05T06:22:35Z","lastAt":"2011-01-06T05:00:25Z","messageCount":2,"participants":["Albert Dvornik"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"158946","messageId":"AANLkTikhaPP0bHEEeFf_2RgK_bdE-i+gaCKopfQjqgHP@mail.gmail.com","threadId":"26198","inReplyTo":null,"subject":"\"git svn fetch\" on a branch is broken after \"git svn reset\"","fromName":"Albert Dvornik","fromEmail":"dvornik+git@gmail.com","sentAt":"2011-01-05T06:22:35Z","receivedAt":"2011-01-05T06:22:35Z","isPatch":false,"sender":{"key":"dvornik+git@gmail.com","avatar":null},"body":"The documentation for git svn claims that this should work:\n\n    git svn reset -r2 -p\n    git svn fetch\n\nBut when I tried it (using an SVN tree that has recent commits only in\na branch, not the trunk), it didn't work correctly.  \"fetch\" grabbed\njust the latest version from SVN, and not all revs from <revnum> to\nthe head!  Note that it matters that this is in an SVN branch-- if I\nrepeat the test using revs in the trunk, everything works as expected.\n\nSpecifically, what I did was this:\n\n    git co -b testing refs/remotes/test-branch\n    git svn fetch\n\n    git svn reset -r 850\n    # does correctly rewind to rev 850, undoing commits in test-branch\n\n    git svn fetch\n    # oops, only fetches the *head* revision (rev 856) from SVN!\n    # In refs/remotes/test-branch, SVN rev 850 is now followed by 856!\n\nI then tried this again, but between reset and fetching I manually\nedited .git/svn/.metadata and moved back the *-maxRev versions to 850;\nafter doing this, the fetch does the right thing.  I tried examining\nthe logic in git-svn.perl to figure out why this happens and why it\nwould be affecting a branch but not the trunk, but I didn't get very\nfar.\n\nI can reproduce the problem on Linux (git version 1.7.2.1) and Windows\n(Git for Windows version 1.7.3.2.msysgit.0.4.ga4f3f or Cygwin git\n1.7.2.3).\n\nThoughts?\n\n--bert\n"},{"id":"159019","messageId":"AANLkTikMjj1PFRQCs7N58Y+GCruEHv1FZc1OPN4r9Yr1@mail.gmail.com","threadId":"26198","inReplyTo":"AANLkTikhaPP0bHEEeFf_2RgK_bdE-i+gaCKopfQjqgHP@mail.gmail.com","subject":"Re: \"git svn fetch\" on a branch is broken after \"git svn reset\"","fromName":"Albert Dvornik","fromEmail":"dvornik+git@gmail.com","sentAt":"2011-01-06T05:00:25Z","receivedAt":"2011-01-06T05:00:25Z","isPatch":false,"sender":{"key":"dvornik+git@gmail.com","avatar":null},"body":"Here is a reproducer using a very simple public SVN repo.\n\n[I spent a bit of effort on trying to figure out what's going on, but\ngit-svn code, er, has a learning curve. =)  After a reset, fetch_all()\ncorrectly backs up $base when fetching on the trunk, but not on the\nbranch, because $gs->rev_map_max returns a correctly reset value in\none case but not the other.  This may be because $fetch ALWAYS seems\nto refer to the trunk; is that supposed to be the case?]\n\n--bert Dvornik\n\nOn Wed, Jan 5, 2011 at 1:22 AM, Albert Dvornik <dvornik+git@gmail.com> wrote:\n> The documentation for git svn claims that this should work:\n>\n>    git svn reset -r2 -p\n>    git svn fetch\n>\n> But when I tried it (using an SVN tree that has recent commits only in\n> a branch, not the trunk), it didn't work correctly.  \"fetch\" grabbed\n> just the latest version from SVN, and not all revs from <revnum> to\n> the head!  Note that it matters that this is in an SVN branch-- if I\n> repeat the test using revs in the trunk, everything works as expected.\n>\n> Specifically, what I did was this:\n>\n>    git co -b testing refs/remotes/test-branch\n>    git svn fetch\n>\n>    git svn reset -r 850\n>    # does correctly rewind to rev 850, undoing commits in test-branch\n>\n>    git svn fetch\n>    # oops, only fetches the *head* revision (rev 856) from SVN!\n>    # In refs/remotes/test-branch, SVN rev 850 is now followed by 856!\n>\n> I then tried this again, but between reset and fetching I manually\n> edited .git/svn/.metadata and moved back the *-maxRev versions to 850;\n> after doing this, the fetch does the right thing.  I tried examining\n> the logic in git-svn.perl to figure out why this happens and why it\n> would be affecting a branch but not the trunk, but I didn't get very\n> far.\n>\n> I can reproduce the problem on Linux (git version 1.7.2.1) and Windows\n> (Git for Windows version 1.7.3.2.msysgit.0.4.ga4f3f or Cygwin git\n> 1.7.2.3).\n>\n> Thoughts?\n>\n> --bert\n>\n"}]}