Eric Wong <normalperson@xxxxxxxx> writes:
> Seth Falcon <sethfalcon@xxxxxxxxx> wrote:
>> Eric Wong <normalperson@xxxxxxxx> writes:
>>
>> > Seth Falcon <sethfalcon@xxxxxxxxx> wrote:
>> >> Eric: is there any way to undo some of the svn revs that have been
>> >> retrieved using git-svn fetch and then refetch them?
>>
>> > Assuming you're not using something crazy like noMetadata, you can just
>> > use update-ref on the remote heads to the last known good revisions and
>> > remove the associated .rev_db files.
>> >
>> > Otherwise you'll have to delete entries from the .rev_db files, the
>> > format is one line per-revision, the revision is the line number of the
>> > file.
>>
>> Hmm, not sure I understood. Here's what I tried:
>>
>> I'm tracking two branches via git-svn. For each, I used git log
>> remotes/<branch> to find a revision that I expect to be ok and noted
>> the sha1. Then I did:
>>
>> git-update-ref remotes/git-svn a27b11c1
>
> You may need to specify "refs/": "refs/remotes/git-svn".
> Is there a .git/remotes/git-svn ref file now?
Yes. I removed those and redid the git-update-ref specifying
refs/remotes/git-svn and the branch I have.
>> Did I miss a step or misunderstand how to undo? What's strange is
>> that if I do git show 0f12c8c, I see a patch that is looks like it came
>> from a fetch using the my broken version of git-svn -- do I need to
>> clear out objects before refetching?
>
> I might have left some steps (I've been all over the place lately :/).
> You probably need to do all that and also need to edit
> .git/svn/.metadata and set the {branches,tags}-maxRev fields to the last
> known good revisions if you use globs.
I ran git-gc --prune. I also took a look at .git/svn/.metadata, but
all I have there is:
; This file is used internally by git-svn
; You should not have to edit it
[svn-remote "svn"]
uuid = 00db46b3-68df-0310-9c12-caf00c1e9a41
So I left that alone. I tried refetching and end up with the
following error after the rev dbs were rebuilt:
error: invalid object 67e31e0ada47e8e9d15547ff1a48298869b3907b
fatal: git-write-tree: error building trees
write-tree: command returned error: 128
I found a backup of this repository and will use that. Since I have a
backup, it isn't worth the effort. I think the obvious lesson is to
use a copy of a repos when testing git-svn so you can throw it away if
things go awry.
+ seth
-
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