Ben Jackson <ben@xxxxxxx> wrote: > On Mon, Jul 06, 2009 at 02:29:28PM -0700, Eric Wong wrote: > > Yann Dirson <ydirson@xxxxxxxxxxxx> 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 -- 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