{"thread":{"id":"20838","subject":"[PATCH 0/8] VCS helpers","startedAt":"2009-09-04T02:13:43Z","lastAt":"2009-09-04T17:03:22Z","messageCount":4,"participants":["Daniel Barkalow","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":8},"messages":[{"id":"122376","messageId":"alpine.LNX.2.00.0909032213120.28290@iabervon.org","threadId":"20838","inReplyTo":null,"subject":"[PATCH 0/8] VCS helpers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-09-04T02:13:43Z","receivedAt":"2009-09-04T02:13:43Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"This is the next version of the db/vcs-helper series in pu.\n\nThe first patch is new, a rework of the remote-curl build to produce\n\"remote-curl\" and call it as a special case for the sorts of URLs that\nwe accept as indicating something that it now handled by this helper.\n\nThe series is rebased onto current next, with some conflicts resolved.\n\nTwo patches have been dropped: a memory leak fix for code that was\nremoved entirely by the first patch, and the \"mark\" helper capability,\nwhich is not needed (I believe) due to the \"option\" fast-import command.\n\nDaniel Barkalow (8):\n Make the \"traditionally-supported\" URLs a special case\n Use a clearer style to issue commands to remote helpers\n Use a function to determine whether a remote is valid\n Allow fetch to modify refs\n Allow programs to not depend on remotes having urls\n Add a config option for remotes to specify a foreign vcs\n Add support for \"import\" helper command\n Allow helpers to report in \"list\" command that the ref is unchanged\n\n Documentation/config.txt | 4 +\n Documentation/git-remote-helpers.txt | 14 ++++-\n Makefile | 17 +-----\n builtin-clone.c | 6 +-\n builtin-fetch.c | 7 ++-\n builtin-ls-remote.c | 4 +-\n builtin-push.c | 67 +++++++++++++--------\n remote.c | 15 ++++-\n remote.h | 2 +\n transport-helper.c | 107 +++++++++++++++++++++++++++++-----\n transport.c | 23 +++++--\n transport.h | 43 +++++++++++++-\n 12 files changed, 234 insertions(+), 75 deletions(-)\n"},{"id":"122390","messageId":"7v63bz198j.fsf@alter.siamese.dyndns.org","threadId":"20838","inReplyTo":"alpine.LNX.2.00.0909032213120.28290@iabervon.org","subject":"Re: [PATCH 0/8] VCS helpers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-04T07:04:28Z","receivedAt":"2009-09-04T07:04:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> This is the next version of the db/vcs-helper series in pu.\n\nThanks.\n\n> The first patch is new, a rework of the remote-curl build to produce\n> \"remote-curl\" and call it as a special case for the sorts of URLs that\n> we accept as indicating something that it now handled by this helper.\n>\n> The series is rebased onto current next, with some conflicts resolved.\n\nBecause the theme of the topic does not have anything to do with fixing\nthe deepening of shallow clones nor giving an extended error message from\nnon-fast-forward git-push, I queued the series after reverse-rebasing onto\nold db/vcs-helper~8, in order to keep the topic branch pure, instead of\nmerging unrelated topics from maint, master or next into it. The result\nmerged in 'pu' obviously has to match what you expected by applying the\npatches on top of 'next', and I am reasonably sure it does.\n\n> Two patches have been dropped: a memory leak fix for code that was\n> removed entirely by the first patch, and the \"mark\" helper capability,\n> which is not needed (I believe) due to the \"option\" fast-import command.\n\nJohan's cvs-helper series were depending on the previous iteration of this\nseries, but I thought it is being rerolled, so I'd drop it from pu for now.\n"},{"id":"122443","messageId":"alpine.LNX.2.00.0909041141020.28290@iabervon.org","threadId":"20838","inReplyTo":"7v63bz198j.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/8] VCS helpers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-09-04T16:22:20Z","receivedAt":"2009-09-04T16:22:20Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 4 Sep 2009, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > This is the next version of the db/vcs-helper series in pu.\n> \n> Thanks.\n> \n> > The first patch is new, a rework of the remote-curl build to produce\n> > \"remote-curl\" and call it as a special case for the sorts of URLs that\n> > we accept as indicating something that it now handled by this helper.\n> >\n> > The series is rebased onto current next, with some conflicts resolved.\n> \n> Because the theme of the topic does not have anything to do with fixing\n> the deepening of shallow clones nor giving an extended error message from\n> non-fast-forward git-push, I queued the series after reverse-rebasing onto\n> old db/vcs-helper~8, in order to keep the topic branch pure, instead of\n> merging unrelated topics from maint, master or next into it. The result\n> merged in 'pu' obviously has to match what you expected by applying the\n> patches on top of 'next', and I am reasonably sure it does.\n\nI'd thought that topics in pu were carried as based on next, particularly \nonce they depend on something (e.g., the beginning of the series) in next. \nI suppose there's better options, but what do you do to find them? (Feel \nfree to refer me to the \"note from the maintainer\" if it's there, but I \ndon't remember that detail)\n\nFWIW, there was a semantic mismerge in the original basing of this series \non 07a4a3b496, which I finally fixed in this version; the code to handle \nNULL urls in builtin-fetch was after a new conversion of the url.\n\nIn any case, I think both the reverse-rebase and merge are correct.\n\n> > Two patches have been dropped: a memory leak fix for code that was\n> > removed entirely by the first patch, and the \"mark\" helper capability,\n> > which is not needed (I believe) due to the \"option\" fast-import command.\n> \n> Johan's cvs-helper series were depending on the previous iteration of this\n> series, but I thought it is being rerolled, so I'd drop it from pu for now.\n\nYou could probably stick the \"mark\" patch into the start of the cvs-helper \nseries until it gets rerolled if you want to keep that series in pu \nmeanwhile; it was at the end of the series, and doesn't have subtle \ninteractions or interact with anything that's changed.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"122449","messageId":"7vd466lk11.fsf@alter.siamese.dyndns.org","threadId":"20838","inReplyTo":"alpine.LNX.2.00.0909041141020.28290@iabervon.org","subject":"Re: [PATCH 0/8] VCS helpers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-04T17:03:22Z","receivedAt":"2009-09-04T17:03:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> On Fri, 4 Sep 2009, Junio C Hamano wrote:\n>\n>> Because the theme of the topic does not have anything to do with fixing\n>> the deepening of shallow clones nor giving an extended error message from\n>> non-fast-forward git-push, I queued the series after reverse-rebasing onto\n>> old db/vcs-helper~8, in order to keep the topic branch pure, instead of\n>> merging unrelated topics from maint, master or next into it. The result\n>> merged in 'pu' obviously has to match what you expected by applying the\n>> patches on top of 'next', and I am reasonably sure it does.\n>\n> I'd thought that topics in pu were carried as based on next, particularly \n> once they depend on something (e.g., the beginning of the series) in next. \n> I suppose there's better options, but what do you do to find them? (Feel \n> free to refer me to the \"note from the maintainer\" if it's there, but I \n> don't remember that detail)\n\nOh, I was *not* complaining that you gave a patch based on 'next'. I was\nmerely explaining what I did to your patch, in case somebody wonders why\nthe output of \"log -p -8 db/vcs-helper\" looks different from what you\nposted on the list. I also wanted you to verify the result.\n\n> FWIW, there was a semantic mismerge in the original basing of this series \n> on 07a4a3b496, which I finally fixed in this version; the code to handle \n> NULL urls in builtin-fetch was after a new conversion of the url.\n>\n> In any case, I think both the reverse-rebase and merge are correct.\n\nThanks. Actually, the fact your patch was based on 'next' did help me\nverify the result of the rebase and the merge.\n\nIt is a good discipline to spend some extra effort to keep a topic pure if\nand only if the other topics that the topic textually depends on were of\nmore dubious quality than the topioc itself. In such a case, there is no\nguarantee that they graduate ever, and the topic will be blocked without\nmajor effort later.\n\nIt does not matter in practice when we are reasonably sure that other\ntopics that the topic depends on are likely to be already in when the\ntopic is completed. In this particular case, many of the changes the\nreverse rebase needed to remove are in fact already in master and some are\neven in maint, and in retrospect, there was not much point doing this only\nto risk mistakes.\n\nIn fact, I originally merged the commits whose changes overlapped and were\nalready in master (Nico's \"deepening shallow\", Matthieu's \"give better\nwarning to non-fast-forward push\", to name a few) on top of the part of\ndb/vcs-helper that was already in 'next', and then applied your patches on\ntop of the result, as a middle ground solution. The topic would not have\nbeen as pure as the result I pushed out, but it would still have been much\nbetter than merging the whole master before applying the series.\n\nThe principle of keeping the topic branch pure in this case may fall into\nmy OCD ;-).\n"}]}