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.
threads / discuss / 20033
"git svn reset" only resets current branch ?
Subject: "git svn reset" only resets current branch ?
Re: "git svn reset" only resets current branch ?
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
Ben JacksonRe: "git svn reset" only resets current branch ?
On Mon, Jul 06, 2009 at 02:29:28PM -0700, Eric Wong wrote:
Show 10 quoted lines
> 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 ?
Ben Jackson <ben@ben.com> wrote:
Show 27 quoted lines
> 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