{"thread":{"id":"14729","subject":"Hackontest ideas?","startedAt":"2008-07-29T00:01:03Z","lastAt":"2008-08-03T23:36:19Z","messageCount":21,"participants":["Petr Baudis","Miklos Vajna","Tarmigan","Junio C Hamano","Nguyen Thai Ngoc Duy","Shawn O. Pearce","Jakub Narebski","Johannes Schindelin","Luciano Rocha","Avery Pennarun","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"85364","messageId":"20080729000103.GH32184@machine.or.cz","threadId":"14729","inReplyTo":null,"subject":"Hackontest ideas?","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2008-07-29T00:01:03Z","receivedAt":"2008-07-29T00:01:03Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hi,\n\n  participating in this might be fun, even if there is not much time\nleft to sign up:\n\n\thttp://www.hackontest.org/index.php?action=Root-projectDetail(120)\n\n(What feature in Git or a Git-related tool would you implement, given 24\nhours staight and unlimited pizza supply?)\n\n  P.S.: Disclaimer - yes, if someone suggests something cool enough to\ndo with Git, I might apply. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nAs in certain cults it is possible to kill a process if you know\nits true name.  -- Ken Thompson and Dennis M. Ritchie\n"},{"id":"85367","messageId":"20080729001016.GT32057@genesis.frugalware.org","threadId":"14729","inReplyTo":"20080729000103.GH32184@machine.or.cz","subject":"Re: Hackontest ideas?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-07-29T00:10:16Z","receivedAt":"2008-07-29T00:10:16Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis <pasky@ucw.cz> wrote:\n>   participating in this might be fun, even if there is not much time\n> left to sign up:\n> \n> \thttp://www.hackontest.org/index.php?action=Root-projectDetail(120)\n> \n> (What feature in Git or a Git-related tool would you implement, given 24\n> hours staight and unlimited pizza supply?)\n> \n>   P.S.: Disclaimer - yes, if someone suggests something cool enough to\n> do with Git, I might apply. ;-)\n\nRestartable git-clone? :-)\n\nIt was a GSoC idea this year, but in the end nobody started working on\nit.\n\n(I was about to work on it, but finally my 'builtin-merge' application\nwas accepted.)\n"},{"id":"85370","messageId":"905315640807281734r74d47b53oe797e4ef8193af00@mail.gmail.com","threadId":"14729","inReplyTo":"20080729000103.GH32184@machine.or.cz","subject":"Re: Hackontest ideas?","fromName":"Tarmigan","fromEmail":"tarmigan+git@gmail.com","sentAt":"2008-07-29T00:34:50Z","receivedAt":"2008-07-29T00:34:50Z","isPatch":false,"sender":{"key":"tarmigan+git@gmail.com","avatar":null},"body":"On Mon, Jul 28, 2008 at 5:01 PM, Petr Baudis <pasky@ucw.cz> wrote:\n>  participating in this might be fun, even if there is not much time\n> left to sign up:\n>\n>        http://www.hackontest.org/index.php?action=Root-projectDetail(120)\n>\n> (What feature in Git or a Git-related tool would you implement, given 24\n> hours staight and unlimited pizza supply?)\n>\n>  P.S.: Disclaimer - yes, if someone suggests something cool enough to\n> do with Git, I might apply. ;-)\n\nIt might be cool if git-daemon supported\navahi/zeroconf/bonjour/rendezvous as a server and maybe git-status(?\nor maybe a new command) had a flag that could make it an avahi client\nand list repositories on the local network being advertised over\navahi.\n\nIt looks like bzr has an avahi plugin.  Not sure whether it would be a\nuseful feature for people.  What do other folks think?\n\nAs a project, it seems fairly self-contained and well defined, and\nmight be doable for a small team in 24 hours.\n\n-Tarmigan\n"},{"id":"85373","messageId":"7vk5f5o6em.fsf@gitster.siamese.dyndns.org","threadId":"14729","inReplyTo":"20080729000103.GH32184@machine.or.cz","subject":"Re: Hackontest ideas?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-29T00:55:45Z","receivedAt":"2008-07-29T00:55:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@ucw.cz> writes:\n\n> (What feature in Git or a Git-related tool would you implement, given 24\n> hours staight and unlimited pizza supply?)\n\n\"Use 'assume unchanged' bit to implement narrow checkout\".\n"},{"id":"85374","messageId":"7vfxpto5ys.fsf@gitster.siamese.dyndns.org","threadId":"14729","inReplyTo":"20080729000103.GH32184@machine.or.cz","subject":"Re: Hackontest ideas?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-29T01:05:15Z","receivedAt":"2008-07-29T01:05:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@ucw.cz> writes:\n\n> (What feature in Git or a Git-related tool would you implement, given 24\n> hours staight and unlimited pizza supply?)\n\n\"git-merge-blame\"\n(http://git.or.cz/gitwiki/SoC2007Ideas#head-cfde15f16950c2579a89cc109762e911546e6fe3).\n"},{"id":"85375","messageId":"20080729011404.GI32184@machine.or.cz","threadId":"14729","inReplyTo":"7vk5f5o6em.fsf@gitster.siamese.dyndns.org","subject":"Re: Hackontest ideas?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-29T01:14:04Z","receivedAt":"2008-07-29T01:14:04Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:\n> Petr Baudis <pasky@ucw.cz> writes:\n> \n> > (What feature in Git or a Git-related tool would you implement, given 24\n> > hours staight and unlimited pizza supply?)\n> \n> \"Use 'assume unchanged' bit to implement narrow checkout\".\n\nI think Nguyen Thai Ngoc Duy is already working on this? (Though I think\nhe does not use the assume unchanged bit; but this will be likely done\nbefore the end of September.)\n\n(This is a bit annoying, by the way - the deadline is way too early...)\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"85380","messageId":"fcaeb9bf0807281855w3b06f624q18f5ac76a3bb405c@mail.gmail.com","threadId":"14729","inReplyTo":"20080729011404.GI32184@machine.or.cz","subject":"Re: Hackontest ideas?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-29T01:55:32Z","receivedAt":"2008-07-29T01:55:32Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:\n> On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:\n>  > Petr Baudis <pasky@ucw.cz> writes:\n>  >\n>  > > (What feature in Git or a Git-related tool would you implement, given 24\n>  > > hours staight and unlimited pizza supply?)\n>  >\n>  > \"Use 'assume unchanged' bit to implement narrow checkout\".\n>\n>\n> I think Nguyen Thai Ngoc Duy is already working on this? (Though I think\n>  he does not use the assume unchanged bit; but this will be likely done\n>  before the end of September.)\n\nYou are welcome to do ;) I got to narrow checkout from subtree\ncheckout where 'assume unchanged' bit was unapplicable so my approach\nis a bit different, but probably 'assume unchanged' bit is the right\nway to go.\n\n-- \nDuy\n"},{"id":"85382","messageId":"20080729020212.GI10151@machine.or.cz","threadId":"14729","inReplyTo":"fcaeb9bf0807281855w3b06f624q18f5ac76a3bb405c@mail.gmail.com","subject":"Re: Hackontest ideas?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-29T02:02:12Z","receivedAt":"2008-07-29T02:02:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Jul 29, 2008 at 08:55:32AM +0700, Nguyen Thai Ngoc Duy wrote:\n> On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:\n> > On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:\n> >  > Petr Baudis <pasky@ucw.cz> writes:\n> >  >\n> >  > > (What feature in Git or a Git-related tool would you implement, given 24\n> >  > > hours staight and unlimited pizza supply?)\n> >  >\n> >  > \"Use 'assume unchanged' bit to implement narrow checkout\".\n> >\n> >\n> > I think Nguyen Thai Ngoc Duy is already working on this? (Though I think\n> >  he does not use the assume unchanged bit; but this will be likely done\n> >  before the end of September.)\n> \n> You are welcome to do ;) I got to narrow checkout from subtree\n> checkout where 'assume unchanged' bit was unapplicable so my approach\n> is a bit different, but probably 'assume unchanged' bit is the right\n> way to go.\n\nBut I rather liked the elegancy of just narrowing this down to a\nparticular subtree. Is there really a good reason to generalize this\nfurther?\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"85384","messageId":"fcaeb9bf0807281912t4df1b5cap8f1ff33138fda25e@mail.gmail.com","threadId":"14729","inReplyTo":"20080729020212.GI10151@machine.or.cz","subject":"Re: Hackontest ideas?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-29T02:12:04Z","receivedAt":"2008-07-29T02:12:04Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:\n> On Tue, Jul 29, 2008 at 08:55:32AM +0700, Nguyen Thai Ngoc Duy wrote:\n>  > On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:\n>  > > On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:\n>  > >  > Petr Baudis <pasky@ucw.cz> writes:\n>  > >  >\n>  > >  > > (What feature in Git or a Git-related tool would you implement, given 24\n>  > >  > > hours staight and unlimited pizza supply?)\n>  > >  >\n>  > >  > \"Use 'assume unchanged' bit to implement narrow checkout\".\n>  > >\n>  > >\n>  > > I think Nguyen Thai Ngoc Duy is already working on this? (Though I think\n>  > >  he does not use the assume unchanged bit; but this will be likely done\n>  > >  before the end of September.)\n>  >\n>  > You are welcome to do ;) I got to narrow checkout from subtree\n>  > checkout where 'assume unchanged' bit was unapplicable so my approach\n>  > is a bit different, but probably 'assume unchanged' bit is the right\n>  > way to go.\n>\n>\n> But I rather liked the elegancy of just narrowing this down to a\n>  particular subtree. Is there really a good reason to generalize this\n>  further?\n\nI think because it's doable and people do need to narrow to more than\none subtree sometimes. Also it would solve \".git* in parent\ndirectories\" problem that is really hard if you strictly do \"narrow\ndown to a particular subtree\".\n\n-- \nDuy\n"},{"id":"85411","messageId":"20080729053110.GD11947@spearce.org","threadId":"14729","inReplyTo":"20080729001016.GT32057@genesis.frugalware.org","subject":"Re: Hackontest ideas?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-29T05:31:10Z","receivedAt":"2008-07-29T05:31:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Miklos Vajna <vmiklos@frugalware.org> wrote:\n> On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis <pasky@ucw.cz> wrote:\n> > \n> > (What feature in Git or a Git-related tool would you implement, given 24\n> > hours staight and unlimited pizza supply?)\n> \n> Restartable git-clone? :-)\n> \n> It was a GSoC idea this year, but in the end nobody started working on\n> it.\n> \n> (I was about to work on it, but finally my 'builtin-merge' application\n> was accepted.)\n\nYea, we eventually decided it was probably too small for a\nGSoC project.  Given how quickly you put together your git-merge\nproject, I'm actually happy we got you working on git-merge and\nnot restartable clone, as I think you may have finished restartable\nclone in 24 hours and then said \"now what mr. mentor?\" ;-)\n\n\nPasky, et.al.:\n\nHow about smart fetch/push over HTTP?  E.g. a CGI (or extension to\ngitweb) that does native pack transport over HTTP rather than dumb\nobject traversal with GET and WebDAV LOCK/PUT.  Note that the push\nside doesn't need to support tell-me-more extension, making it a\nfairly trivial GET, POST (or PUT) sequence.\n\n-- \nShawn.\n"},{"id":"85433","messageId":"20080729083522.GJ10151@machine.or.cz","threadId":"14729","inReplyTo":"20080729053110.GD11947@spearce.org","subject":"Re: Hackontest ideas?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-29T08:35:22Z","receivedAt":"2008-07-29T08:35:22Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Jul 28, 2008 at 10:31:10PM -0700, Shawn O. Pearce wrote:\n> How about smart fetch/push over HTTP?  E.g. a CGI (or extension to\n> gitweb) that does native pack transport over HTTP rather than dumb\n> object traversal with GET and WebDAV LOCK/PUT.  Note that the push\n> side doesn't need to support tell-me-more extension, making it a\n> fairly trivial GET, POST (or PUT) sequence.\n\nAh, thanks for reminding me about this, nice!\n\nThanks all for their suggestions so far, I have added all of them plus\nan extra. Now, if you want them implemented, some of you need to join as\nimplementers and the features need to get a lot of votes quickly! ;-))\n\n(Frankly, I don't think there is really any chance to make it, but I\nthink having such a list of mid-size self-contained tasks might be\nuseful for other occasions, so I will haul it over to the wiki after the\ndeadline.)\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"85441","messageId":"m3myk1t54c.fsf@localhost.localdomain","threadId":"14729","inReplyTo":"20080729000103.GH32184@machine.or.cz","subject":"Re: Hackontest ideas?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-29T09:24:43Z","receivedAt":"2008-07-29T09:24:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis <pasky@ucw.cz> writes:\n\n>   Hi,\n> \n>   participating in this might be fun, even if there is not much time\n> left to sign up:\n> \n> \thttp://www.hackontest.org/index.php?action=Root-projectDetail(120)\n> \n> (What feature in Git or a Git-related tool would you implement, given 24\n> hours staight and unlimited pizza supply?)\n\nA few ideas (some might be repeated)\n * resumable clone\n * git-push implemented as CGI\n * support for ftp, ftps, sftp fetch\n * support for gits (git over SSL/TLS) fetch\n * relative blame, i.e. if you have blame data for some revision\n   (for example in \"git gui blame\") you want to have data for some\n   revision which is either direct ancestor or direct descendant\n   of the revision you have blame data for, aka \"git blame --relative\"\n * \"tree\" blame, i.e. something like VievVC or GitHub shows:\n   for exach entry in a tree commit which brought it to current version\n * graph log for gitweb, either generating images on the fly, or using\n   a few pre-defined images ('|', '-', '\\', '/', etc.) and CSS.\n * \"MediaWiki history\"-like or \"MoinMoin info\"-like view for gitweb\n * improvements to \"git log --follow\" so it works also for nonlinear\n   history (for example \"git log --follow gitweb/gitweb.perl\" following\n   to the very first version of gitweb, then as gitweb.cgi)\n * graphical history viewer for Git mode in Emacs.\n * context sensitive searching in gitweb, for example searching\n   commits on given branch, or grepping files in given directory\n * handling of svn:externals using submodules\n * custom merge strategy for ChangeLog, for .po files\n\nBlame merge strategy would take probably much more that 24h solely\nin the initial design phase...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"85452","messageId":"alpine.DEB.1.00.0807291354130.4631@eeepc-johanness","threadId":"14729","inReplyTo":"m3myk1t54c.fsf@localhost.localdomain","subject":"git-svn and svn:externals, was Re: Hackontest ideas?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-29T11:56:37Z","receivedAt":"2008-07-29T11:56:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 Jul 2008, Jakub Narebski wrote:\n\n>  * handling of svn:externals using submodules\n\nI doubt that this is easy.  Otherwise, Eric would have done it a long time \nago.\n\nThe main concern I have is to get the semantics right: AFAICT \nsvn:externals has _no notion_ of \"what is current\".  It just _always_ \nfetches the HEAD.  Even if you check out an ancient revision in the \n\"superproject\".\n\nCiao,\nDscho\n"},{"id":"85457","messageId":"200807291428.32072.jnareb@gmail.com","threadId":"14729","inReplyTo":"alpine.DEB.1.00.0807291354130.4631@eeepc-johanness","subject":"Re: git-svn and svn:externals, was Re: Hackontest ideas?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-29T12:28:31Z","receivedAt":"2008-07-29T12:28:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 29 Jul 2008, Jakub Narebski wrote:\n> \n> >  * handling of svn:externals using submodules\n> \n> I doubt that this is easy.  Otherwise, Eric would have done it a long time \n> ago.\n\nYeah, I guess is too large a project for Hackontest.\n \n> The main concern I have is to get the semantics right: AFAICT \n> svn:externals has _no notion_ of \"what is current\".  It just _always_ \n> fetches the HEAD.  Even if you check out an ancient revision in the \n> \"superproject\".\n\nIf I understand correctly with version 1.5 svn:externals can be\nspecified using \"peg revisions\", so they could refer to some specific\nrevision of 'external', like git submodules.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"85465","messageId":"alpine.DEB.1.00.0807291502450.4631@eeepc-johanness","threadId":"14729","inReplyTo":"200807291428.32072.jnareb@gmail.com","subject":"Re: git-svn and svn:externals, was Re: Hackontest ideas?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-29T13:04:14Z","receivedAt":"2008-07-29T13:04:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 Jul 2008, Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Tue, 29 Jul 2008, Jakub Narebski wrote:\n> > \n> > >  * handling of svn:externals using submodules\n> > \n> > The main concern I have is to get the semantics right: AFAICT \n> > svn:externals has _no notion_ of \"what is current\".  It just _always_ \n> > fetches the HEAD.  Even if you check out an ancient revision in the \n> > \"superproject\".\n> \n> If I understand correctly with version 1.5 svn:externals can be \n> specified using \"peg revisions\", so they could refer to some specific \n> revision of 'external', like git submodules.\n\n... which only means that if they had done that from the beginning, it \nthe git-svn enhancement would be easy.\n\nBut as they did not have it from the beginning, anybody tackling git-svn \nand svn:externals will have to come up with sensible semantics for the \nhard case.\n\nCiao,\nDscho\n"},{"id":"85468","messageId":"20080729130823.GB30334@bit.office.eurotux.com","threadId":"14729","inReplyTo":"alpine.DEB.1.00.0807291354130.4631@eeepc-johanness","subject":"Re: git-svn and svn:externals, was Re: Hackontest ideas?","fromName":"Luciano Rocha","fromEmail":"luciano@eurotux.com","sentAt":"2008-07-29T13:08:23Z","receivedAt":"2008-07-29T13:08:23Z","isPatch":false,"sender":{"key":"luciano@eurotux.com","avatar":null},"body":"On Tue, Jul 29, 2008 at 01:56:37PM +0200, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 29 Jul 2008, Jakub Narebski wrote:\n> \n> >  * handling of svn:externals using submodules\n> \n> I doubt that this is easy.  Otherwise, Eric would have done it a long time \n> ago.\n> \n> The main concern I have is to get the semantics right: AFAICT \n> svn:externals has _no notion_ of \"what is current\".  It just _always_ \n> fetches the HEAD.  Even if you check out an ancient revision in the \n> \"superproject\".\n\nUsually, yes. But you could specify a specific revision with -r <rev>.\n\nOr, for branches/tags, as they're paths, a correct url would suffice.\n\nWith the new 1.5, it is also possible to specify pegged revisions. Much\nbetter, because otherwise subversion would require that the path existed\nin the server in HEAD.\n\n-- \nLuciano Rocha <luciano@eurotux.com>\nEurotux Informática, S.A. <http://www.eurotux.com/>\n"},{"id":"85470","messageId":"alpine.DEB.1.00.0807291516120.4631@eeepc-johanness","threadId":"14729","inReplyTo":"20080729130823.GB30334@bit.office.eurotux.com","subject":"Re: git-svn and svn:externals, was Re: Hackontest ideas?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-29T13:17:21Z","receivedAt":"2008-07-29T13:17:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 Jul 2008, Luciano Rocha wrote:\n\n> On Tue, Jul 29, 2008 at 01:56:37PM +0200, Johannes Schindelin wrote:\n> \n> > On Tue, 29 Jul 2008, Jakub Narebski wrote:\n> > \n> > >  * handling of svn:externals using submodules\n> > \n> > The main concern I have is to get the semantics right: AFAICT \n> > svn:externals has _no notion_ of \"what is current\".  It just _always_ \n> > fetches the HEAD.  Even if you check out an ancient revision in the \n> > \"superproject\".\n> \n> Usually, yes. But you could specify a specific revision with -r <rev>.\n\nI do not see how that helps defining the semantics for git-svn at all.\n\n> With the new 1.5, it is also possible to specify pegged revisions. Much \n> better, because otherwise subversion would require that the path existed \n> in the server in HEAD.\n\nAs I already commented, the possibility (and for most svn repositories, \nthe likelihood) that nothing is pegged makes this less helpful, either.\n\nCiao,\nDscho\n"},{"id":"85484","messageId":"32541b130807290908l13e753d8t1357db452a04f491@mail.gmail.com","threadId":"14729","inReplyTo":"alpine.DEB.1.00.0807291502450.4631@eeepc-johanness","subject":"Re: git-svn and svn:externals, was Re: Hackontest ideas?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-29T16:08:55Z","receivedAt":"2008-07-29T16:08:55Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/29/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n>  On Tue, 29 Jul 2008, Jakub Narebski wrote:\n>  > If I understand correctly with version 1.5 svn:externals can be\n>  > specified using \"peg revisions\", so they could refer to some specific\n>  > revision of 'external', like git submodules.\n>\n> ... which only means that if they had done that from the beginning, it\n>  the git-svn enhancement would be easy.\n>\n>  But as they did not have it from the beginning, anybody tackling git-svn\n>  and svn:externals will have to come up with sensible semantics for the\n>  hard case.\n\nOne option would be to simply attach the submodule to the \"latest\ncommit of the svn:external at the time the supermodule svn commit was\nmade\".  Basically, enforce git-submodule's precise revision feature\nretroactively onto svn:externals.\n\nI think this would be perfectly fine in my own projects, for example:\nit's what I wanted in the first place, but svn didn't have this\nfeature, so I faked it by branching/tagging the external repo whenever\nI wanted to link to a particular revision.\n\nHave fun,\n\nAvery\n"},{"id":"86116","messageId":"20080803224852.GC3006@untitled","threadId":"14729","inReplyTo":"alpine.DEB.1.00.0807291354130.4631@eeepc-johanness","subject":"Re: git-svn and svn:externals, was Re: Hackontest ideas?","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2008-08-03T22:48:52Z","receivedAt":"2008-08-03T22:48:52Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n> \n> On Tue, 29 Jul 2008, Jakub Narebski wrote:\n> \n> >  * handling of svn:externals using submodules\n> \n> I doubt that this is easy.  Otherwise, Eric would have done it a long time \n> ago.\n\nI started working on externals support a long time ago, but got hung up\non corner-cases (with .gitmodules and .gitignore being in the tree) and\nbackward-compatibility issues with commiting back to SVN.\n\nThe more I think about it, the more I think the worse-is-better approach\nI used for \"git svn show-ignore\" is the way to go (using the unversioned\n.git/info/exclude).  That would mean ignoring submodules as implemented\nby git and just shotgunning another git-svn-created subdirectory into\nwhere the external would've been...\n\n> The main concern I have is to get the semantics right: AFAICT \n> svn:externals has _no notion_ of \"what is current\".  It just _always_ \n> fetches the HEAD.  Even if you check out an ancient revision in the \n> \"superproject\".\n\nBased on my limited understanding, peg revisions are only needed in SVN\nbecause of the cost of traversing history to DTRT.  git-svn should be\nable to just use the -r<rev> syntax that has always been supported\nwithout needing peg revisions.  On the other hand, implicit rename/copy\ndetection in git may not pick up drastic changes...\n\n-- \nEric Wong\n"},{"id":"86124","messageId":"alpine.DEB.1.00.0808040113150.9611@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"14729","inReplyTo":"20080803224852.GC3006@untitled","subject":"Re: git-svn and svn:externals, was Re: Hackontest ideas?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-03T23:24:28Z","receivedAt":"2008-08-03T23:24:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 3 Aug 2008, Eric Wong wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n>\n> > The main concern I have is to get the semantics right: AFAICT \n> > svn:externals has _no notion_ of \"what is current\".  It just _always_ \n> > fetches the HEAD.  Even if you check out an ancient revision in the \n> > \"superproject\".\n> \n> Based on my limited understanding, peg revisions are only needed in SVN \n> because of the cost of traversing history to DTRT.  git-svn should be \n> able to just use the -r<rev> syntax that has always been supported \n> without needing peg revisions.\n\nI was talking about the svn -> git direction.\n\nAnd Git does not peg revisions because of the cost of traversing history \nto DTRT.\n\nGit pegs revisions of submodules, because it is the right thing to do.  \nSubversion just got it wrong to begin with.  After all, we are going \nthrough a lot to make defined revisions, and we do not want to throw that \nout by allowing an unversioned submodule.\n\nSo, importing a svn:external with git-svn has to undo that error somehow \n(which might be helped by the linearity of subversion, but might be tricky \nbecause of possible clock skews between the two subversion repositories).\n\nCiao,\nDscho\n"},{"id":"86126","messageId":"20080803233619.GC5435@hand.yhbt.net","threadId":"14729","inReplyTo":"alpine.DEB.1.00.0808040113150.9611@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: git-svn and svn:externals, was Re: Hackontest ideas?","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2008-08-03T23:36:19Z","receivedAt":"2008-08-03T23:36:19Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n> \n> On Sun, 3 Aug 2008, Eric Wong wrote:\n> \n> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> >\n> > > The main concern I have is to get the semantics right: AFAICT \n> > > svn:externals has _no notion_ of \"what is current\".  It just _always_ \n> > > fetches the HEAD.  Even if you check out an ancient revision in the \n> > > \"superproject\".\n> > \n> > Based on my limited understanding, peg revisions are only needed in SVN \n> > because of the cost of traversing history to DTRT.  git-svn should be \n> > able to just use the -r<rev> syntax that has always been supported \n> > without needing peg revisions.\n> \n> I was talking about the svn -> git direction.\n\nLikewise.\n\n> And Git does not peg revisions because of the cost of traversing history \n> to DTRT.\n\nI was saying SVN uses peg revisions because of the cost.\nAlso, there may be a misunderstanding as to what peg revisions are (in SVN)\nand how they relate to git.\n\nHere's an example svn:external definition with a peg revision:\n\n  -r 1234 http://foo/bar.c@5233\n\n\"@5233\" is the peg revision, and (as I understand it, just a hint) and\n\"-r 1234\" is the actual revision we want from SVN (and what git-svn\nshould fetch).  Confusing?  Yes.\n\n> Git pegs revisions of submodules, because it is the right thing to do.  \n> Subversion just got it wrong to begin with.  After all, we are going \n> through a lot to make defined revisions, and we do not want to throw that \n> out by allowing an unversioned submodule.\n\nYes, most repositories I've seen don't even use \"-r 1234\" (which has\nalways been supported by SVN).  This is the problem git will have to\ndeal with.\n\n> So, importing a svn:external with git-svn has to undo that error somehow \n> (which might be helped by the linearity of subversion, but might be tricky \n> because of possible clock skews between the two subversion repositories).\n\nYes.  This is why I'm leaning towards /not/ using git submodules for this\nbecause svn:externals are rarely defined with -r <revno>.\n\n-- \nEric Wong\n"}]}