From: Eric Wong <normalperson@yhbt.net>
To: Steven Grimm <koreth@midwinter.com>
Cc: git@vger.kernel.org
Subject: Re: git-svn: follow parent after the fact?
Date: Mon, 18 Dec 2006 23:47:45 -0800 [thread overview]
Message-ID: <20061219074745.GA31338@localdomain> (raw)
In-Reply-To: <45873D0A.1040804@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> One of the other git users here just noticed that his git-svn clone of a
> particular svn repo has an inconsistent set of files compared to the svn
> client. Turns out the repo has had its trunk moved around in the past. A
> fresh clone with --follow-parent (which he didn't use) produces the
> correct results.
The final set of files at the latest (svn) revision was inconsistent?
That should never happen... If so, I'd very much like to look into this.
> Obviously he can blow away his current repo and make a new one, but it'd
> be nicer if he could preserve his local change history. Is there any way
> to retroactively apply the additional changes --follow-parent would have
> applied if it had been used on the initial fetch?
git-svn graft-branches can probably work (if he imported the parent
separately).
> It would be better, IMO, if you didn't have to figure out whether or not
> a given remote svn repository has had branch renames in the past in
> order to figure out if you need to provide an extra option to git-svn
> fetch. Maybe --follow-parent should be the default behavior and there
> should be an option to turn it off? Or is there a good reason to not
> want that behavior most of the time? My assumption is that it's not the
> default simply because it's a recent addition.
It may behave unpredictably on some poorly organized repositories. I
haven't quite debugged this problem fully as the current code to handle
multiple repositories is a hacked-on mess.
I'm currently refactoring git-svn to work better on multi-remote
operations and --follow-parent should be easier to debug as a result.
> By the way, I'm completely in favor of renaming commit to set-tree. +1
> for that change.
Noted, thanks for the input.
--
next prev parent reply other threads:[~2006-12-19 7:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-19 1:14 git-svn: follow parent after the fact? Steven Grimm
2006-12-19 7:47 ` Eric Wong [this message]
2006-12-19 21:36 ` Steven Grimm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061219074745.GA31338@localdomain \
--to=normalperson@yhbt.net \
--cc=git@vger.kernel.org \
--cc=koreth@midwinter.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox