threads / discuss / 20045

Re: "git svn reset" only resets current branch ?

Subject: Re: "git svn reset" only resets current branch ?

## tl;dr

3 messages between Jul 7, 2009 and Jul 7, 2009.

replies: 2people: 3as markdown or json

Yann Dirson· Jul 7, 2009, 08:01 UTC · lore

> I think the current behavior is a reasonable default; it's least
> surprising to me and the user could more easily rerun with "--all" if
> needed.  If --all were the default, the user could potentially
> have to refetch a lot of data they didn't want to.

As an alternative, we could also allow "git svn reset" to take us back into the future to undo any such mistake without refetching.

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 ;)

Ben Jackson· Jul 7, 2009, 18:21 UTC · re: Yann Dirson · lore

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@ben.com>
http://www.ben.com/

Eric Wong· Jul 7, 2009, 20:28 UTC · re: Yann Dirson · lore

Yann Dirson <ydirson@linagora.com> wrote:

Show 12 quoted lines

> > I think the current behavior is a reasonable default; it's least
> > surprising to me and the user could more easily rerun with "--all" if
> > needed.  If --all were the default, the user could potentially
> > have to refetch a lot of data they didn't want to.
> 
> As an alternative, we could also allow "git svn reset" to take us back
> into the future to undo any such mistake without refetching.
> 
> 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 ;)

fetch with --all fetches from all "svn-remotes" defined in the config (it's rare to have more than one). It's roughly equivalent to:

  git remote | xargs -n1 git fetch

As far as reset behavior goes, I'll leave you and Ben to decide how/what to do since I've never used it myself (I rarely even use git svn nowadays).

-- 
Eric Wong