From: Eric Wong <normalperson@yhbt.net>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org
Subject: Re: [RFC] git pull and importers
Date: Sat, 7 Apr 2007 13:24:09 -0700 [thread overview]
Message-ID: <20070407202409.GA5107@muzzle> (raw)
In-Reply-To: <Pine.LNX.4.64.0704062239420.27922@iabervon.org>
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.
"git svn rebase" (in 1.5.1) is handy for getting upstream commits into
your branch (it's a wrapper around "git rebase")
> 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.
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.
> 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.
[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.
--
Eric Wong
next prev parent reply other threads:[~2007-04-07 20:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-07 2:48 [RFC] git pull and importers Daniel Barkalow
2007-04-07 14:21 ` Junio C Hamano
2007-04-07 17:41 ` Daniel Barkalow
2007-04-07 20:24 ` Eric Wong [this message]
2007-04-07 21:32 ` Junio C Hamano
2007-04-07 21:50 ` Eric Wong
2007-04-07 23:12 ` Daniel Barkalow
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=20070407202409.GA5107@muzzle \
--to=normalperson@yhbt.net \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.