{"thread":{"id":"7554","subject":"[RFC] git pull and importers","startedAt":"2007-04-07T02:48:51Z","lastAt":"2007-04-07T23:12:44Z","messageCount":7,"participants":["Daniel Barkalow","Junio C Hamano","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"38836","messageId":"Pine.LNX.4.64.0704062239420.27922@iabervon.org","threadId":"7554","inReplyTo":null,"subject":"[RFC] git pull and importers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-04-07T02:48:51Z","receivedAt":"2007-04-07T02:48:51Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"There's an SVN project I'm trying to track with git-svn. \"git svn fetch\" \nfetches and imports the commits perfectly, but I can't figure out a way to \nmerge upstream commits into my branch automatically.\n\nIt seems like the right solution should be:\n\n[remote \"origin\"]\n\timporter = svn\n\turl = svn://ixion.tartarus.org/main\n\tfetch = puzzles:refs/remotes/puzzles\n[branch \"master\"]\n\tremote = origin\n\tmerge = puzzles\n\nWhich would mean that it would use \"git svn fetch\" instead of \"git fetch\" \nfor that remote, and \"git svn fetch\" would use that config section instead \nof its current config section.\n\nAny reason this couldn't be made to work?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"38843","messageId":"7v1wiwfeo5.fsf@assigned-by-dhcp.cox.net","threadId":"7554","inReplyTo":"Pine.LNX.4.64.0704062239420.27922@iabervon.org","subject":"Re: [RFC] git pull and importers","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-07T14:21:46Z","receivedAt":"2007-04-07T14:21:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Which would mean that it would use \"git svn fetch\" instead of \"git fetch\" \n> for that remote, and \"git svn fetch\" would use that config section instead \n> of its current config section.\n>\n> Any reason this couldn't be made to work?\n\nNo reason. Making git-$(scm)import to behave more like\ngit-fetch-pack backend was one of the longstanding items on my\nwishlist. I think \"cvsimport -i\" could mostly be usable in the\ncurrent shape for that, but I do not know about others.\n\nEspecially I do not interoperate with any SVN repositories\nmyself, so I cannot scratch your itch.\n\nHowever, I suspect you could help me with a code I've been\nstruggling with on-and-off lately. Do you still remember\nunpack-trees code?\n"},{"id":"38856","messageId":"Pine.LNX.4.64.0704071323010.27922@iabervon.org","threadId":"7554","inReplyTo":"7v1wiwfeo5.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git pull and importers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-04-07T17:41:39Z","receivedAt":"2007-04-07T17:41:39Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 7 Apr 2007, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > Which would mean that it would use \"git svn fetch\" instead of \"git fetch\" \n> > for that remote, and \"git svn fetch\" would use that config section instead \n> > of its current config section.\n> >\n> > Any reason this couldn't be made to work?\n> \n> No reason. Making git-$(scm)import to behave more like\n> git-fetch-pack backend was one of the longstanding items on my\n> wishlist. I think \"cvsimport -i\" could mostly be usable in the\n> current shape for that, but I do not know about others.\n\nI picked git-svn in part because it looks especially obvious; it even \ncalls fetch \"fetch\". Not that that *really* counts for much, but I can \npretend.\n\n> Especially I do not interoperate with any SVN repositories\n> myself, so I cannot scratch your itch.\n\nI'll look into it, if the config option scheme looks reasonable to you.\n\n> However, I suspect you could help me with a code I've been\n> struggling with on-and-off lately. Do you still remember\n> unpack-trees code?\n\nI'm not sure how similar it is these days to the code I worked on (which \nwas called \"read-tree\", I think), but I'll take a look.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"38859","messageId":"20070407202409.GA5107@muzzle","threadId":"7554","inReplyTo":"Pine.LNX.4.64.0704062239420.27922@iabervon.org","subject":"Re: [RFC] git pull and importers","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-07T20:24:09Z","receivedAt":"2007-04-07T20:24:09Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Daniel Barkalow wrote:\n> There's an SVN project I'm trying to track with git-svn. \"git svn fetch\" \n> fetches and imports the commits perfectly, but I can't figure out a way to \n> merge upstream commits into my branch automatically.\n\nI don't suggest using merge with git-svn since it can generate\nnon-linear history. Non-linear history does not map well to SVN.\n\n\"git svn rebase\" (in 1.5.1) is handy for getting upstream commits into\nyour branch (it's a wrapper around \"git rebase\")\n\n> It seems like the right solution should be:\n> \n> [remote \"origin\"]\n> \timporter = svn\n> \turl = svn://ixion.tartarus.org/main\n> \tfetch = puzzles:refs/remotes/puzzles\n> [branch \"master\"]\n> \tremote = origin\n> \tmerge = puzzles\n\ngit-svn in 1.5.1 already allows you to define:\n\n[svn-remote \"svn\"]\n\turl = svn://ixion.tartarus.org/main\n\tfetch = puzzles:refs/remotes/puzzles\n\nAnd then \"git svn rebase\" should automatically be able to figure out to\nrebase against refs/remotes/puzzles without needing a [branch \"master\"]\nsection.\n\nI don't think having the \"importer = svn\" in [remote \"...\"] is a good\nidea since it would be incompatible with older versions of git and the\ndocumentation would confuse users who don't track the latest version.\n\n> Which would mean that it would use \"git svn fetch\" instead of \"git fetch\" \n> for that remote, and \"git svn fetch\" would use that config section instead \n> of its current config section.\n\nHere's what I'd like git-fetch to do someday[1]:\n\nWhen git-fetch is called without any remote arguments, it would look for\n[remote \"origin\"] as it does now. However, if no [remote \"...\"]\nsections are found (as is common with importer-created repos), it would\ntry other importers: [svn-remote \"svn\"], (and hopefully one day\n[cvs-remote \"cvs\"], [arch-remote \"arch\"], ...).\n\nOf course, git-fetch would also be able to handle --svn (and later\n--cvs/--arch/...) flags if the [*remote \"...\"] section names are\nambiguous.\n\nI intentionally named the default svn-remote section \"svn\" instead of\n\"origin\" for this reason, too; I didn't want to confuse git-fetch.\n\n[1] - patches would be very much welcome (*nudge*nudge*wink*wink),\n I have a lot on my plate and this isn't a high priority.\n\n-- \nEric Wong\n"},{"id":"38864","messageId":"7vr6qvc1kl.fsf@assigned-by-dhcp.cox.net","threadId":"7554","inReplyTo":"20070407202409.GA5107@muzzle","subject":"Re: [RFC] git pull and importers","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-07T21:32:58Z","receivedAt":"2007-04-07T21:32:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong writes:\n\n> When git-fetch is called without any remote arguments, it would look for\n> [remote \"origin\"] as it does now. However, if no [remote \"...\"]\n> sections are found (as is common with importer-created repos), it would\n> try other importers: [svn-remote \"svn\"], (and hopefully one day\n> [cvs-remote \"cvs\"], [arch-remote \"arch\"], ...).\n\nI wonder why wouldn't the alternative of noticing the URL scheme\nof '[remote \"svn\"] url' variable is \"svn://\". That is...\n\n\t[remote \"gitrepo\"]\n \turl = git://example.com/repo.git/\n\t\tfetch = refs/heads/*:refs/remotes/gitrepo/*\n\t[remote \"svnrepo\"]\n \turl = svn://example.com/repo.svn/\n fetch = trunk:refs/remotes/svnrepo/trunk\n\t[remote \"cvsrepo\"]\n \turl = cvs://example.com/repo.cvs/\n fetch = HEAD:refs/remotes/cvsrepo/\n\nThe sections would probably can have importer specific options\nbesides usual url/fetch.\n"},{"id":"38868","messageId":"20070407215027.GA20424@hand.yhbt.net","threadId":"7554","inReplyTo":"7vr6qvc1kl.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git pull and importers","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-07T21:50:28Z","receivedAt":"2007-04-07T21:50:28Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano wrote:\n> Eric Wong writes:\n> \n> > When git-fetch is called without any remote arguments, it would look for\n> > [remote \"origin\"] as it does now. However, if no [remote \"...\"]\n> > sections are found (as is common with importer-created repos), it would\n> > try other importers: [svn-remote \"svn\"], (and hopefully one day\n> > [cvs-remote \"cvs\"], [arch-remote \"arch\"], ...).\n> \n> I wonder why wouldn't the alternative of noticing the URL scheme\n> of '[remote \"svn\"] url' variable is \"svn://\". That is...\n\nSVN repositories can also be http:// or https://, too.\n\n-- \nEric Wong\n"},{"id":"38869","messageId":"Pine.LNX.4.64.0704071808580.27922@iabervon.org","threadId":"7554","inReplyTo":"20070407202409.GA5107@muzzle","subject":"Re: [RFC] git pull and importers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-04-07T23:12:44Z","receivedAt":"2007-04-07T23:12:44Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 7 Apr 2007, Eric Wong wrote:\n\n> Daniel Barkalow wrote:\n> > There's an SVN project I'm trying to track with git-svn. \"git svn fetch\" \n> > fetches and imports the commits perfectly, but I can't figure out a way to \n> > merge upstream commits into my branch automatically.\n> \n> I don't suggest using merge with git-svn since it can generate\n> non-linear history. Non-linear history does not map well to SVN.\n\nThat depends entirely on your merge strategy. In this case, I'm only \nreally interested in fast-forwards, which can't create, well, anything. If \nI did any development on this particular project, I'd be emailing patch \nseries, at least for now, so mapping back into SVN isn't a concern for me.\n\n> \"git svn rebase\" (in 1.5.1) is handy for getting upstream commits into\n> your branch (it's a wrapper around \"git rebase\")\n\nPossibly \"pull\" should be able to invoke rebase instead of merge, also\n(or merge should be able to actually use rebase). Handwaving, it would be \ngood if a branch config could say that the history has to remain linear \nfor some policy reason.\n\n> > It seems like the right solution should be:\n> > \n> > [remote \"origin\"]\n> > \timporter = svn\n> > \turl = svn://ixion.tartarus.org/main\n> > \tfetch = puzzles:refs/remotes/puzzles\n> > [branch \"master\"]\n> > \tremote = origin\n> > \tmerge = puzzles\n> \n> git-svn in 1.5.1 already allows you to define:\n> \n> [svn-remote \"svn\"]\n> \turl = svn://ixion.tartarus.org/main\n> \tfetch = puzzles:refs/remotes/puzzles\n> \n> And then \"git svn rebase\" should automatically be able to figure out to\n> rebase against refs/remotes/puzzles without needing a [branch \"master\"]\n> section.\n\nThat's what I've got right now.\n\n> I don't think having the \"importer = svn\" in [remote \"...\"] is a good\n> idea since it would be incompatible with older versions of git and the\n> documentation would confuse users who don't track the latest version.\n\nThe current version of git just ignores it, which means that a regular \n\"git fetch\" fails, but actually somewhat less confusingly than if you \ndon't have the section at all. (See below)\n\n> > Which would mean that it would use \"git svn fetch\" instead of \"git fetch\" \n> > for that remote, and \"git svn fetch\" would use that config section instead \n> > of its current config section.\n> \n> Here's what I'd like git-fetch to do someday[1]:\n> \n> When git-fetch is called without any remote arguments, it would look for\n> [remote \"origin\"] as it does now. However, if no [remote \"...\"]\n> sections are found (as is common with importer-created repos), it would\n> try other importers: [svn-remote \"svn\"], (and hopefully one day\n> [cvs-remote \"cvs\"], [arch-remote \"arch\"], ...).\n> \n> Of course, git-fetch would also be able to handle --svn (and later\n> --cvs/--arch/...) flags if the [*remote \"...\"] section names are\n> ambiguous.\n> \n> I intentionally named the default svn-remote section \"svn\" instead of\n> \"origin\" for this reason, too; I didn't want to confuse git-fetch.\n\ngit-fetch is confused worse by getting invoked without any remotes than by \ngetting a URL that doesn't work. I think it's trying to fetch from \n\"./origin/.git\" effectively. At least if you've got a section with a URL \nthat doesn't have a git repository at it, it tells you it couldn't find a \ngit repository at the svn URL (or it tells you it doesn't understand \nsvn://...), at which point you know what's wrong.\n\nFor future versions, it would be just as easy to have a setting to tell it \nwhat interfacing thing it needs in order to handle a particular remote.\n\nBut I could see it being helpful to be able to have a ton of different \nremotes, some of which are through importers, where you don't much care \nhow you get the content. E.g., Linus could just do \"git pull alsa\", to \nimport from ALSA's repository, ignoring the fact that it's hg (and used \nto be cvs). It would definitely be helpful for cases where changes only \ncome from the foriegn SCM (or go back as patches). So, at the very least, \nyou should be able to use:\n\n[hg-remote \"alsa\"]\n\nAlso, subprojects in the \"vast superproject\" model would often have \nimport-only links to upstream repositories in other systems, as a backbone \nfor non-linear local development.\n\n> [1] - patches would be very much welcome (*nudge*nudge*wink*wink),\n> I have a lot on my plate and this isn't a high priority.\n\nI've been poking at the git-fetch stuff some. Certainly doing better than \nlooking at git-svn, since I don't know perl...\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}