{"thread":{"id":"8648","subject":"builtin-fetch code with messy history","startedAt":"2007-06-19T07:12:04Z","lastAt":"2007-06-19T19:47:14Z","messageCount":11,"participants":["Daniel Barkalow","Johannes Schindelin","Alex Riesen","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45321","messageId":"Pine.LNX.4.64.0706190255430.4740@iabervon.org","threadId":"8648","inReplyTo":null,"subject":"builtin-fetch code with messy history","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-19T07:12:04Z","receivedAt":"2007-06-19T07:12:04Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"In my branch at: git://iabervon.org/~barkalow/git builtin-fetch\n\nI have a bunch of not-for-merging history leading up to a C version of \nfetch which passes all of the tests except that:\n\n * it might be fetching too much with --depth.\n * bundle isn't implemented.\n * when a branch config file section refers to a branches/* remote, the \n merge setting is used (if one is given), even though this isn't useful \n either way.\n * branch..merge is treated like the source side of a refspec \n (although it cannot be a wildcard), and it fetched refs are marked for \n merging if they name the same ref, even if they are not character-wise \n identical to the source side of the refspec used to fetch them.\n\nI've got more work to do on it (such as actually using my parser for \nparsing the refspecs and making the logic less convoluted), but I thought \nI'd report my progress.\n\nI'll give a sign-off to anyone who extracts patches that can be applied, \nif anybody wants to.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"45334","messageId":"Pine.LNX.4.64.0706191037590.4059@racer.site","threadId":"8648","inReplyTo":"Pine.LNX.4.64.0706190255430.4740@iabervon.org","subject":"Re: builtin-fetch code with messy history","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-19T09:40:27Z","receivedAt":"2007-06-19T09:40:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 Jun 2007, Daniel Barkalow wrote:\n\n> In my branch at: git://iabervon.org/~barkalow/git builtin-fetch\n> \n> I have a bunch of not-for-merging history leading up to a C version of \n> fetch which passes all of the tests except that:\n> \n> * it might be fetching too much with --depth.\n\nThat should be fixable. (If I get more time this week than I expect, I'll \ndo it myself.)\n\n> * bundle isn't implemented.\n\nThat's an easy one.\n\n> * when a branch config file section refers to a branches/* remote, the \n> merge setting is used (if one is given), even though this isn't useful \n> either way.\n\nMaybe this is the right time to cut off branches/* and remotes/*?\n\n> * branch..merge is treated like the source side of a refspec \n> (although it cannot be a wildcard), and it fetched refs are marked for \n> merging if they name the same ref, even if they are not character-wise \n> identical to the source side of the refspec used to fetch them.\n> \n> I've got more work to do on it (such as actually using my parser for \n> parsing the refspecs and making the logic less convoluted), but I \n> thought I'd report my progress.\n\nThank you very much!\nDscho\n"},{"id":"45338","messageId":"81b0412b0706190313g74765babk38309dd838f3f585@mail.gmail.com","threadId":"8648","inReplyTo":"Pine.LNX.4.64.0706191037590.4059@racer.site","subject":"Re: builtin-fetch code with messy history","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-19T10:13:06Z","receivedAt":"2007-06-19T10:13:06Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 6/19/07, Johannes Schindelin wrote:\n> > * when a branch config file section refers to a branches/* remote, the\n> > merge setting is used (if one is given), even though this isn't useful\n> > either way.\n>\n> Maybe this is the right time to cut off branches/* and remotes/*?\n>\n\nSeconded. Don't use the remotes/ since some months now.\nBut... isn't a git package with code of something like 1.4.4 is still\nin some major distributions?\n"},{"id":"45340","messageId":"Pine.LNX.4.64.0706191210020.4059@racer.site","threadId":"8648","inReplyTo":"81b0412b0706190313g74765babk38309dd838f3f585@mail.gmail.com","subject":"Re: builtin-fetch code with messy history","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-19T11:11:55Z","receivedAt":"2007-06-19T11:11:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 Jun 2007, Alex Riesen wrote:\n\n> On 6/19/07, Johannes Schindelin wrote:\n> > > * when a branch config file section refers to a branches/* remote, the\n> > > merge setting is used (if one is given), even though this isn't useful\n> > > either way.\n> > \n> > Maybe this is the right time to cut off branches/* and remotes/*?\n> \n> Seconded. Don't use the remotes/ since some months now.\n> But... isn't a git package with code of something like 1.4.4 is still\n> in some major distributions?\n\nYes, AFAICT it is Ubuntu \"the most up-to-date distro there is\". At least \nmany questions on the list and in IRC suggest that.\n\nSo, how about checking (at least for a year) in builtin-fetch, if \n\"branches/\" or \"remotes/\" exist, and fail, with a nice message how to move \nto config-based remotes?\n\nCiao,\nDscho\n"},{"id":"45343","messageId":"81b0412b0706190447y37c3aedbya42b7a3d5703322c@mail.gmail.com","threadId":"8648","inReplyTo":"Pine.LNX.4.64.0706191210020.4059@racer.site","subject":"Re: builtin-fetch code with messy history","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-19T11:47:12Z","receivedAt":"2007-06-19T11:47:12Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 6/19/07, Johannes Schindelin wrote:\n> > >\n> > > Maybe this is the right time to cut off branches/* and remotes/*?\n> >\n> > Seconded. Don't use the remotes/ since some months now.\n> > But... isn't a git package with code of something like 1.4.4 is still\n> > in some major distributions?\n>\n> Yes, AFAICT it is Ubuntu \"the most up-to-date distro there is\". At least\n> many questions on the list and in IRC suggest that.\n>\n> So, how about checking (at least for a year) in builtin-fetch, if\n> \"branches/\" or \"remotes/\" exist, and fail, with a nice message how to move\n> to config-based remotes?\n\n...by suggesting to use a nice conversion script which we don't\nhave.\n\nBTW, as far as I can see, git-remote reads old configuration just fine,\nso it probably will a very simple script: read all and write all. Well,\nthe \"all\" part of it can be a bit complicated, but aside from that...\n"},{"id":"45345","messageId":"Pine.LNX.4.64.0706191249480.4059@racer.site","threadId":"8648","inReplyTo":"81b0412b0706190447y37c3aedbya42b7a3d5703322c@mail.gmail.com","subject":"Re: builtin-fetch code with messy history","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-19T11:51:04Z","receivedAt":"2007-06-19T11:51:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 Jun 2007, Alex Riesen wrote:\n\n> On 6/19/07, Johannes Schindelin wrote:\n> > > >\n> > > > Maybe this is the right time to cut off branches/* and remotes/*?\n> > >\n> > > Seconded. Don't use the remotes/ since some months now.\n> > > But... isn't a git package with code of something like 1.4.4 is still\n> > > in some major distributions?\n> > \n> > Yes, AFAICT it is Ubuntu \"the most up-to-date distro there is\". At least\n> > many questions on the list and in IRC suggest that.\n> > \n> > So, how about checking (at least for a year) in builtin-fetch, if\n> > \"branches/\" or \"remotes/\" exist, and fail, with a nice message how to move\n> > to config-based remotes?\n> \n> ...by suggesting to use a nice conversion script which we don't\n> have.\n\ngit.git/contrib/remotes2config.sh\n\nIIRC it was explicitely asked to leave branches/* out of that script, but \nthe original version had it, and it should be easy to include it again.\n\n> BTW, as far as I can see, git-remote reads old configuration just fine,\n> so it probably will a very simple script: read all and write all. Well,\n> the \"all\" part of it can be a bit complicated, but aside from that...\n\nCiao,\nDscho\n"},{"id":"45346","messageId":"81b0412b0706190457l730d9b6ehc87471808e553c37@mail.gmail.com","threadId":"8648","inReplyTo":"Pine.LNX.4.64.0706191249480.4059@racer.site","subject":"Re: builtin-fetch code with messy history","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-19T11:57:00Z","receivedAt":"2007-06-19T11:57:00Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 6/19/07, Johannes Schindelin wrote:\n> > On 6/19/07, Johannes Schindelin wrote:\n> > > > >\n> > > > > Maybe this is the right time to cut off branches/* and remotes/*?\n> > > >\n> > > > Seconded. Don't use the remotes/ since some months now.\n> > > > But... isn't a git package with code of something like 1.4.4 is still\n> > > > in some major distributions?\n> > >\n> > > Yes, AFAICT it is Ubuntu \"the most up-to-date distro there is\". At least\n> > > many questions on the list and in IRC suggest that.\n> > >\n> > > So, how about checking (at least for a year) in builtin-fetch, if\n> > > \"branches/\" or \"remotes/\" exist, and fail, with a nice message how to move\n> > > to config-based remotes?\n> >\n> > ...by suggesting to use a nice conversion script which we don't\n> > have.\n>\n> git.git/contrib/remotes2config.sh\n>\n> IIRC it was explicitely asked to leave branches/* out of that script, but\n> the original version had it, and it should be easy to include it again.\n\nRight, missed it. Sounds like we have a plan\n"},{"id":"45368","messageId":"f59194$odb$1@sea.gmane.org","threadId":"8648","inReplyTo":"Pine.LNX.4.64.0706191037590.4059@racer.site","subject":"Re: builtin-fetch code with messy history","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-06-19T16:46:29Z","receivedAt":"2007-06-19T16:46:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n>>  * when a branch config file section refers to a branches/* remote, the \n>>    merge setting is used (if one is given), even though this isn't useful \n>>    either way.\n> \n> Maybe this is the right time to cut off branches/* and remotes/*?\n\nWe should read branches/* and remotes/* for a long time; even if people\nare using new version of git, their repositories are not necessarily\nconverted (and IIRC there is only script for remotes -> config, in contrib,\nnot in core git).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"45367","messageId":"Pine.LNX.4.64.0706191239260.4740@iabervon.org","threadId":"8648","inReplyTo":"Pine.LNX.4.64.0706191037590.4059@racer.site","subject":"Re: builtin-fetch code with messy history","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-19T16:49:40Z","receivedAt":"2007-06-19T16:49:40Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 19 Jun 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Tue, 19 Jun 2007, Daniel Barkalow wrote:\n> \n> > In my branch at: git://iabervon.org/~barkalow/git builtin-fetch\n> > \n> > I have a bunch of not-for-merging history leading up to a C version of \n> > fetch which passes all of the tests except that:\n> > \n> > * it might be fetching too much with --depth.\n> \n> That should be fixable. (If I get more time this week than I expect, I'll \n> do it myself.)\n\nI just haven't taken the time to look at what it's supposed to do exactly, \nsince I wasn't paying attention to the discussions there.\n\n> > * bundle isn't implemented.\n> \n> That's an easy one.\n\nYeah, just a section in transport.c about it, but the functions I need \naren't available directly and I got distracted until I was looking at my \nlist of what tests I'd disabled.\n\n> > * when a branch config file section refers to a branches/* remote, the \n> > merge setting is used (if one is given), even though this isn't useful \n> > either way.\n> \n> Maybe this is the right time to cut off branches/* and remotes/*?\n\nIt's not actually too difficult to support them, except for some weird \ncombination cases that nobody would do anyway. I just made the remote.c \nconfig file parser generate the corresponding configurations from them, \nand the rest of the code doesn't have to care. The only oddity is that I \nhad to support having a remote always auto-follow tags, even without \ntracking branches, because that's what branches/* did. But this is \nprobably a reasonable thing to support as an option anyway.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"45371","messageId":"7vodjbx2t2.fsf@assigned-by-dhcp.pobox.com","threadId":"8648","inReplyTo":"Pine.LNX.4.64.0706191239260.4740@iabervon.org","subject":"Re: builtin-fetch code with messy history","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-19T17:38:17Z","receivedAt":"2007-06-19T17:38:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n>> > * when a branch config file section refers to a branches/* remote, the \n>> > merge setting is used (if one is given), even though this isn't useful \n>> > either way.\n>> \n>> Maybe this is the right time to cut off branches/* and remotes/*?\n>\n> It's not actually too difficult to support them, except for some weird \n> combination cases that nobody would do anyway. I just made the remote.c \n> config file parser generate the corresponding configurations from them, \n> and the rest of the code doesn't have to care. The only oddity is that I \n> had to support having a remote always auto-follow tags, even without \n> tracking branches, because that's what branches/* did. But this is \n> probably a reasonable thing to support as an option anyway.\n\nWe should support repositories with older layouts for an\neternity in git timescale (that is usually 6mo to a year) after\nannouncing that they are deprecated (which hasn't happened yet,\nbut I think everybody agrees that deprecating branches/ and\nremotes/ is a sane thing to do in 1.6.0 or so). Even if we give\nclear migration path and script, having to convert them all at\nonce is a nuisance for the users.\n"},{"id":"45375","messageId":"Pine.LNX.4.64.0706192043310.4059@racer.site","threadId":"8648","inReplyTo":"Pine.LNX.4.64.0706191239260.4740@iabervon.org","subject":"Re: builtin-fetch code with messy history","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-19T19:47:14Z","receivedAt":"2007-06-19T19:47:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 19 Jun 2007, Daniel Barkalow wrote:\n\n> On Tue, 19 Jun 2007, Johannes Schindelin wrote:\n> \n> > \n> > On Tue, 19 Jun 2007, Daniel Barkalow wrote:\n> > \n> > > In my branch at: git://iabervon.org/~barkalow/git builtin-fetch\n> > > \n> > > I have a bunch of not-for-merging history leading up to a C version \n> > > of fetch which passes all of the tests except that:\n> > > \n> > > * it might be fetching too much with --depth.\n> > \n> > That should be fixable. (If I get more time this week than I expect, \n> > I'll do it myself.)\n> \n> I just haven't taken the time to look at what it's supposed to do \n> exactly, since I wasn't paying attention to the discussions there.\n\nCome to think of it, I am not sure that it does the right thing in \nexisting code either. There are still a bunch of emails regarding shallow \nclone in my inbox, awaiting calmer weather.\n\n> > > * bundle isn't implemented.\n> > \n> > That's an easy one.\n> \n> Yeah, just a section in transport.c about it, but the functions I need \n> aren't available directly and I got distracted until I was looking at my \n> list of what tests I'd disabled.\n\nWhat I meant is not that it is so easy that you should have done it. I \nmeant that this is so easy you should not bother with it, since I'll \ngladly step in once builtin-fetch is otherwise feature complete.\n\n> > > * when a branch config file section refers to a branches/* remote, the \n> > > merge setting is used (if one is given), even though this isn't useful \n> > > either way.\n> > \n> > Maybe this is the right time to cut off branches/* and remotes/*?\n> \n> It's not actually too difficult to support them, except for some weird \n> combination cases that nobody would do anyway. I just made the remote.c \n> config file parser generate the corresponding configurations from them, \n> and the rest of the code doesn't have to care. The only oddity is that I \n> had to support having a remote always auto-follow tags, even without \n> tracking branches, because that's what branches/* did. But this is \n> probably a reasonable thing to support as an option anyway.\n\nAs Junio said, I think in the interest of clean code we should \ndeprecate that, and eventually get rid of it. We could do that even before \nbuiltin-fetch reaches 'next'...\n\nCiao,\nDscho\n"}]}