"git svn reset" only resets current branch ?

"git svn reset" only resets current branch ?

[Yann Dirson]

I just tried the new "git svn reset" from master, and got puzzled that
only the svn branch which is an ancestor of current git HEAD got rolled
back.  Is that the expected behaviour ?  It would not make it very easy to
fixup imports from svn trees with lots of branches/tags.

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

[Eric Wong]

Yann Dirson <ydirson@linagora.com> wrote:
> I just tried the new "git svn reset" from master, and got puzzled that
> only the svn branch which is an ancestor of current git HEAD got rolled
> back.  Is that the expected behaviour ?  It would not make it very easy to
> fixup imports from svn trees with lots of branches/tags.

Ben was the original implementer of this idea, so I'm not sure of his
reasoning behind it.  For one, it's easier to only roll back one svn
branch.  Perhaps adding an --all flag to this command would be the best
way to go?

-- 
Eric Wong

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

[Ben Jackson]

On Mon, Jul 06, 2009 at 02:29:28PM -0700, Eric Wong wrote:
> Yann Dirson <ydirson@linagora.com> wrote:
> > I just tried the new "git svn reset" from master, and got puzzled that
> > only the svn branch which is an ancestor of current git HEAD got rolled
> > back.  Is that the expected behaviour ?  It would not make it very easy to
> > fixup imports from svn trees with lots of branches/tags.
> 
> Ben was the original implementer of this idea, so I'm not sure of his
> reasoning behind it.  For one, it's easier to only roll back one svn
> branch.  Perhaps adding an --all flag to this command would be the best
> way to go?

The only SVN repos I use git-svn with are either too huge and complex to
fully import with git (up to r135000 at work) or too small to have any
branches (all the various open source projects I've git-svn cloned).  So
the main reason it works that way is that I've never really used git-svn
with branches.

Eric,

Do you expect that it would work to reset one branch and re-fetch it
without touching the other branches?  If not, it would probably imply:

Should cmd_reset always loop over all remotes like cmd_multi_fetch?

As the "opposite of fetch" should it take '--all' and conditionally
loop?

Yann,

It would help if you made a test case (or extended t9139-git-svn-reset.sh)
that illustrated the problem and the desired behavior.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

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

[Eric Wong]

Ben Jackson <ben@ben.com> wrote:
> On Mon, Jul 06, 2009 at 02:29:28PM -0700, Eric Wong wrote:
> > Yann Dirson <ydirson@linagora.com> wrote:
> > > I just tried the new "git svn reset" from master, and got puzzled that
> > > only the svn branch which is an ancestor of current git HEAD got rolled
> > > back.  Is that the expected behaviour ?  It would not make it very easy to
> > > fixup imports from svn trees with lots of branches/tags.
> > 
> > Ben was the original implementer of this idea, so I'm not sure of his
> > reasoning behind it.  For one, it's easier to only roll back one svn
> > branch.  Perhaps adding an --all flag to this command would be the best
> > way to go?
> 
> The only SVN repos I use git-svn with are either too huge and complex to
> fully import with git (up to r135000 at work) or too small to have any
> branches (all the various open source projects I've git-svn cloned).  So
> the main reason it works that way is that I've never really used git-svn
> with branches.
> 
> Eric,
> 
> Do you expect that it would work to reset one branch and re-fetch it
> without touching the other branches?  If not, it would probably imply:
> 
> Should cmd_reset always loop over all remotes like cmd_multi_fetch?
> 
> As the "opposite of fetch" should it take '--all' and conditionally
> loop?

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.

-- 
Eric Wong

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

[Yann Dirson]

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

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

[Ben Jackson]

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/

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

[Eric Wong]

Yann Dirson <ydirson@linagora.com> wrote:
> > 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

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

[Yann Dirson]

> 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.

Well, adding --all would probably be better after all.