On Sat, 7 Apr 2007, Eric Wong wrote:

quoted text
> Daniel Barkalow <barkalow@iabervon.org> wrote:
> > There's an SVN project I'm trying to track with git-svn. "git svn fetch" 
> > fetches and imports the commits perfectly, but I can't figure out a way to 
> > merge upstream commits into my branch automatically.
> 
> I don't suggest using merge with git-svn since it can generate
> non-linear history.  Non-linear history does not map well to SVN.

That depends entirely on your merge strategy. In this case, I'm only 
really interested in fast-forwards, which can't create, well, anything. If 
I did any development on this particular project, I'd be emailing patch 
series, at least for now, so mapping back into SVN isn't a concern for me.

quoted text
> "git svn rebase" (in 1.5.1) is handy for getting upstream commits into
> your branch (it's a wrapper around "git rebase")

Possibly "pull" should be able to invoke rebase instead of merge, also
(or merge should be able to actually use rebase). Handwaving, it would be 
good if a branch config could say that the history has to remain linear 
for some policy reason.

quoted text
> > It seems like the right solution should be:
> > 
> > [remote "origin"]
> > 	importer = svn
> > 	url = svn://ixion.tartarus.org/main
> > 	fetch = puzzles:refs/remotes/puzzles
> > [branch "master"]
> > 	remote = origin
> > 	merge = puzzles
> 
> git-svn in 1.5.1 already allows you to define:
> 
> [svn-remote "svn"]
> 	url = svn://ixion.tartarus.org/main
> 	fetch = puzzles:refs/remotes/puzzles
> 
> And then "git svn rebase" should automatically be able to figure out to
> rebase against refs/remotes/puzzles without needing a [branch "master"]
> section.

That's what I've got right now.

quoted text
> I don't think having the "importer = svn" in [remote "..."] is a good
> idea since it would be incompatible with older versions of git and the
> documentation would confuse users who don't track the latest version.

The current version of git just ignores it, which means that a regular 
"git fetch" fails, but actually somewhat less confusingly than if you 
don't have the section at all. (See below)

quoted text
> > Which would mean that it would use "git svn fetch" instead of "git fetch" 
> > for that remote, and "git svn fetch" would use that config section instead 
> > of its current config section.
> 
> Here's what I'd like git-fetch to do someday[1]:
> 
> When git-fetch is called without any remote arguments, it would look for
> [remote "origin"] as it does now.  However, if no [remote "..."]
> sections are found (as is common with importer-created repos), it would
> try other importers: [svn-remote "svn"], (and hopefully one day
> [cvs-remote "cvs"], [arch-remote "arch"], ...).
> 
> Of course, git-fetch would also be able to handle --svn (and later
> --cvs/--arch/...) flags if the [*remote "..."] section names are
> ambiguous.
> 
> I intentionally named the default svn-remote section "svn" instead of
> "origin" for this reason, too; I didn't want to confuse git-fetch.

git-fetch is confused worse by getting invoked without any remotes than by 
getting a URL that doesn't work. I think it's trying to fetch from 
"./origin/.git" effectively. At least if you've got a section with a URL 
that doesn't have a git repository at it, it tells you it couldn't find a 
git repository at the svn URL (or it tells you it doesn't understand 
svn://...), at which point you know what's wrong.

For future versions, it would be just as easy to have a setting to tell it 
what interfacing thing it needs in order to handle a particular remote.

But I could see it being helpful to be able to have a ton of different 
remotes, some of which are through importers, where you don't much care 
how you get the content. E.g., Linus could just do "git pull alsa", to 
import from ALSA's repository, ignoring the fact that it's hg (and used 
to be cvs). It would definitely be helpful for cases where changes only 
come from the foriegn SCM (or go back as patches). So, at the very least, 
you should be able to use:

[hg-remote "alsa"]

Also, subprojects in the "vast superproject" model would often have 
import-only links to upstream repositories in other systems, as a backbone 
for non-linear local development.

quoted text
> [1] - patches would be very much welcome (*nudge*nudge*wink*wink),
>       I have a lot on my plate and this isn't a high priority.

I've been poking at the git-fetch stuff some. Certainly doing better than 
looking at git-svn, since I don't know perl...

	-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html