On Tue, Jul 07, 2009 at 10:01:08AM +0200, Yann Dirson wrote: > > As an alternative, we could also allow "git svn reset" to take us back > into the future to undo any such mistake without refetching. You can't do that directly, since data is destroyed (specifically, the rev_map is truncated back to the selected revision). However, you can "git reset" the branch back to where it was using the reflog, and then the next git-svn command you run will rebuild the rev_map from the comment metadata (obviously you're out of luck if you set "no_metadata"). It's possible that "git-svn reset" should be saving something like ORIG_HEAD (comments welcome) but that does conflict with the idea of adding "--all" or defaulting to "--all" behavior. > I'm not sure it would be the best to keep reset act on a single branch, > where eg. fetch acts on all branches, and already has a --all flag, which > is not yet documented, and seems to have a different meaning (if that > wasn't obvious, I have still not had a look at what it really does ;) Right, I don't really grok the branch thing on the fetch side either. I was hoping for guidance from people who use it on what the expected behavior is. I see even branch users are fuzzy. ;-) The one area where I can definitely see a potential problem is if you reset/refetched one branch (and the revs actually changed, eg due to permissions changes or --ignore-paths changes) and then did a merge. On the other hand, the documentation already suggests you not try to do SVN branch merges with git-svn. -- Ben Jackson AD7GD <ben@xxxxxxx> http://www.ben.com/ -- 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