{"thread":{"id":"36671","subject":"[PATCH] remote-helpers: point at their upstream repositories","startedAt":"2014-05-15T22:56:29Z","lastAt":"2014-05-20T21:50:33Z","messageCount":40,"participants":["Junio C Hamano","Felipe Contreras","Jeff King","Paolo Ciarrocchi","James Denholm","Matthieu Moy","Michael Haggerty","Johan Herland"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"241798","messageId":"xmqqa9aid52a.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":null,"subject":"[PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-15T22:56:29Z","receivedAt":"2014-05-15T22:56:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Two announcements for their version 0.2 on the list archive are not\nquite enough to advertise them to their users.\n\nSigned-off-by: Junio C Hamano \n---\n\n * I am inclined to queue this for 2.0, and we would also need an\n update to the release notes as well.\n\n I am undecided about the revert I sent earlier in $gmane/248937;\n with or without it, that is just a contrib/ thing that is not\n well maintained inside our tree anyway.\n\n contrib/remote-helpers/README | 11 +++++++++++\n 1 file changed, 11 insertions(+)\n create mode 100644 contrib/remote-helpers/README\n\ndiff --git a/contrib/remote-helpers/README b/contrib/remote-helpers/README\nnew file mode 100644\nindex 0000000..72a2df4\n--- /dev/null\n+++ b/contrib/remote-helpers/README\n@@ -0,0 +1,11 @@\n+The remote-helper bridges to access data stored in Hg and bzr will be\n+maintained outside the git.git tree in the repositories of its\n+primary author at:\n+\n+ https://github.com/felipec/git-remote-hg\n+ https://github.com/felipec/git-remote-bzr\n+\n+As a convenience, copies of the last-bundled version of these two\n+remote-helper bridges are kept here, but they may left stale. Users\n+are encouraged to visit the above authoritative repositories for the\n+latest versions to get involved in its further developments.\n-- \n2.0.0-rc3-431-gba4c34e\n"},{"id":"241854","messageId":"5375c01f77285_7e7b772f8f0@nysa.notmuch","threadId":"36671","inReplyTo":"xmqqa9aid52a.fsf@gitster.dls.corp.google.com","subject":"RE: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-16T07:37:03Z","receivedAt":"2014-05-16T07:37:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Two announcements for their version 0.2 on the list archive are not\n> quite enough to advertise them to their users.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> \n> * I am inclined to queue this for 2.0, and we would also need an\n> update to the release notes as well.\n> \n> I am undecided about the revert I sent earlier in $gmane/248937;\n> with or without it, that is just a contrib/ thing that is not\n> well maintained inside our tree anyway.\n> \n> contrib/remote-helpers/README | 11 +++++++++++\n> 1 file changed, 11 insertions(+)\n> create mode 100644 contrib/remote-helpers/README\n\nNAK.\n\n> diff --git a/contrib/remote-helpers/README b/contrib/remote-helpers/README\n> new file mode 100644\n> index 0000000..72a2df4\n> --- /dev/null\n> +++ b/contrib/remote-helpers/README\n> @@ -0,0 +1,11 @@\n> +The remote-helper bridges to access data stored in Hg and bzr will be\n\nThey are called Mercurial and Bazaar.\n\n> +maintained outside the git.git tree in the repositories of its\n> +primary author at:\n> +\n> + https://github.com/felipec/git-remote-hg\n> + https://github.com/felipec/git-remote-bzr\n\nIf this is formatted in asciidoc the links won't appear as links. Do it\nas I did:\n\n * https://github.com/felipec/git-remote-hg\n * https://github.com/felipec/git-remote-bzr\n\n> +As a convenience, copies of the last-bundled version of these two\n> +remote-helper bridges are kept here, but they may left stale. Users\n> +are encouraged to visit the above authoritative repositories for the\n> +latest versions to get involved in its further developments.\n\n 1) Most users will *never* see this README\n 2) Most packagers will never see this README\n 3) The people that do read this README will wonder *why* they are now\n maintained separately.\n\nThanks for wasting all my hard work and sabotaging these projects.\n\nJust as a heads-up. I *will* complain about this publicly and my blog is\nvisited by thousands of people.\n\nI am requesting one last time:\n\n 1) Add warnings *directly* into the tools themselves ASAP\n \n You didn't have any problems adding warnings for pre-v2.0 behavior\n that changed, nor did you have a problem adding the warning about\n the new zsh completion that moved out of the bash one. Why would you\n have a problem with this one?\n\n 2) Replace the tools with stubs that point to the right locations at\n the earliest convenience\n\nI already sent patches for both, and they were ignored.\n\nA failure to do both will result in a lack of visibility of the new\nprojects, and a decrease in the quality the users of git.git contrib\narea's remote-helpers receive. I will consider that a deliberate attempt\nto make the new projects experience unnecessary hardship.\n\n-- \nFelipe Contreras\n"},{"id":"241862","messageId":"20140516084126.GB21468@sigill.intra.peff.net","threadId":"36671","inReplyTo":"xmqqa9aid52a.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-16T08:41:26Z","receivedAt":"2014-05-16T08:41:26Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote:\n\n> Two announcements for their version 0.2 on the list archive are not\n> quite enough to advertise them to their users.\n\nI do not think this README nor a mention in the release notes will get\ntheir attention either, and many people (and packagers) will continue to\nuse the stale versions forever until those versions go away.\n\nI would much rather _replace_ them with a README in the long run, and\npeople will notice that they are gone, and then use the README to update\ntheir install procedure.\n\nFor 2.0, I am hesitant to do that, though I do not have a problem with a\nREADME like this as a heads-up to prepare packagers for the future. I\nsay hesitant because people may have been test-packaging 2.0.0-rc3 in\npreparation for release, and it will be annoying to them to suddenly\nswitch.\n\nBut that being said, this is Felipe's code. While we have a legal right\nto distribute it in v2.0, if he would really prefer it out for v2.0, I\nwould respect that.\n\nI would prefer to instrument the code with warnings, as that is the sort\nof thing a packager moving from -rc3 to -final might not notice, and\nshipping the warnings to end users who did not package the software in\nthe first place will not help them. It is the attention of the packagers\n(and source-builders) you want to get.\n\nOf course that is all just my two cents, and is mostly predicated on\nthere _being_ packagers of the contrib/ tools. It looks like there is a\nDebian package in RFP status, but I don't know if that is following the\nnew release closely. And I don't know about other systems.\n\n-Peff\n"},{"id":"241864","messageId":"CAHVLzc=FcT6BcwX=kx7WKNqod4S0ePmvh5p+sgnQfWTPQ=7yTA@mail.gmail.com","threadId":"36671","inReplyTo":"20140516084126.GB21468@sigill.intra.peff.net","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2014-05-16T08:55:54Z","receivedAt":"2014-05-16T08:55:54Z","isPatch":true,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On Fri, May 16, 2014 at 10:41 AM, Jeff King wrote:\n> But that being said, this is Felipe's code. While we have a legal right\n> to distribute it in v2.0, if he would really prefer it out for v2.0, I\n> would respect that.\n\nMy understanding is that Felipe would prefer to keep it _in_ the git.git\nrepository and eventually get it included in the core.\n\nRegards,\n-- \nPaolo\n"},{"id":"241865","messageId":"20140516085914.GA26118@sigill.intra.peff.net","threadId":"36671","inReplyTo":"CAHVLzc=FcT6BcwX=kx7WKNqod4S0ePmvh5p+sgnQfWTPQ=7yTA@mail.gmail.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-16T08:59:14Z","receivedAt":"2014-05-16T08:59:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 16, 2014 at 10:55:54AM +0200, Paolo Ciarrocchi wrote:\n\n> On Fri, May 16, 2014 at 10:41 AM, Jeff King wrote:\n> > But that being said, this is Felipe's code. While we have a legal right\n> > to distribute it in v2.0, if he would really prefer it out for v2.0, I\n> > would respect that.\n> \n> My understanding is that Felipe would prefer to keep it _in_ the git.git\n> repository and eventually get it included in the core.\n\nYes, sorry if I was unclear. I meant \"...if we are going to remove it,\nand are considering leaving it in v2.0, we should respect his wishes to\nremove it earlier if he wants to\".\n\nIt is not his decision whether it stays in the core at all. That is\nJunio's decision.\n\n-Peff\n"},{"id":"241867","messageId":"5375d4516e48e_1a1b8d330874@nysa.notmuch","threadId":"36671","inReplyTo":"CAHVLzc=FcT6BcwX=kx7WKNqod4S0ePmvh5p+sgnQfWTPQ=7yTA@mail.gmail.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-16T09:03:13Z","receivedAt":"2014-05-16T09:03:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Paolo Ciarrocchi wrote:\n> On Fri, May 16, 2014 at 10:41 AM, Jeff King wrote:\n> > But that being said, this is Felipe's code. While we have a legal right\n> > to distribute it in v2.0, if he would really prefer it out for v2.0, I\n> > would respect that.\n> \n> My understanding is that Felipe would prefer to keep it _in_ the git.git\n> repository and eventually get it included in the core.\n\nThat is correct.\n\n-- \nFelipe Contreras\n"},{"id":"241870","messageId":"5375d903dd6c_1a1b8d33081f@nysa.notmuch","threadId":"36671","inReplyTo":"20140516084126.GB21468@sigill.intra.peff.net","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-16T09:23:15Z","receivedAt":"2014-05-16T09:23:15Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote:\n> \n> > Two announcements for their version 0.2 on the list archive are not\n> > quite enough to advertise them to their users.\n> \n> I do not think this README nor a mention in the release notes will get\n> their attention either, and many people (and packagers) will continue to\n> use the stale versions forever until those versions go away.\n> \n> I would much rather _replace_ them with a README in the long run, and\n> people will notice that they are gone, and then use the README to update\n> their install procedure.\n> \n> For 2.0, I am hesitant to do that, though I do not have a problem with a\n> README like this as a heads-up to prepare packagers for the future. I\n> say hesitant because people may have been test-packaging 2.0.0-rc3 in\n> preparation for release, and it will be annoying to them to suddenly\n> switch.\n\nI agree, that's why I sent patches that:\n\n 1) Add a warning for v2.0 (which already has problems)\n\n So everything keeps working as well as in the release candidates,\n except a warning is introduced each time they do a fetch, push, or\n clone operation (use the remote-helpers)\n\n 2) Replace the tools with stubs\n\n So when they try to fetch, push, or clone, they get an error, and\n nothing else happens.\n\nThere's an additional README for the people that want to read more, but\nif you don't put stubs, users might try to do what worked before:\n\n % git clone hg::http://selenic.com/repo/hello\n fatal: Unable to find remote helper for 'hg'\n\nIt's much better to report:\n\n git-remote-hg is now maintained independently.\n For more information visit https://github.com/felipec/git-remote-hg\n\n> But that being said, this is Felipe's code. While we have a legal right\n> to distribute it in v2.0, if he would really prefer it out for v2.0, I\n> would respect that.\n\nThat's right, you have the legal right to distributed it.\n\nIt is not my wish to disrupt v2.0, so I think adding a warning should be\nsufficient.\n\nEventually I would prefer if they were not distributed, and replaced\nwith stubs, not just because it would help the out-of-tree projects\ngather more visibility, but also because users would be better served by\nnot having poorly maintained or unsynchronized code. Hopefully for v2.1.\n\n> I would prefer to instrument the code with warnings, as that is the sort\n> of thing a packager moving from -rc3 to -final might not notice, and\n> shipping the warnings to end users who did not package the software in\n> the first place will not help them. It is the attention of the packagers\n> (and source-builders) you want to get.\n> \n> Of course that is all just my two cents, and is mostly predicated on\n> there _being_ packagers of the contrib/ tools. It looks like there is a\n> Debian package in RFP status, but I don't know if that is following the\n> new release closely. And I don't know about other systems.\n\nAs far as I understand most distributions don't do anything special with\ncontrib, they just put everything under /usr/share.\n\nIt is unlikely packagers will notice any change in one of the dozens\ntools in contrib, so they'll make no changes to the packages.\n\nSo if the user did:\n\n % ln -s /usr/share/git/remote-helpers/git-remote-hg ~/bin/git-remote-hg\n\nThe expectation would be that this keeps working even if the package\ndoesn't change (it just adds a warning). Eventually it will stop working\nwith an error, but the package still won't change.\n\nThe distributions that do something special about remote-helpers (AFAIK\nit's only debian's git-bzr) would need to change, and sooner or later\nthey will if there's only stubs there.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"241983","messageId":"xmqq8uq1br9c.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"20140516084126.GB21468@sigill.intra.peff.net","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-16T16:52:15Z","receivedAt":"2014-05-16T16:52:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote:\n>\n>> Two announcements for their version 0.2 on the list archive are not\n>> quite enough to advertise them to their users.\n>\n> I do not think this README nor a mention in the release notes will get\n> their attention either, and many people (and packagers) will continue to\n> use the stale versions forever until those versions go away.\n>\n> I would much rather _replace_ them with a README in the long run, and\n> people will notice that they are gone, and then use the README to update\n> their install procedure.\n>\n> For 2.0, I am hesitant to do that, though I do not have a problem with a\n> README like this as a heads-up to prepare packagers for the future. I\n> say hesitant because people may have been test-packaging 2.0.0-rc3 in\n> preparation for release, and it will be annoying to them to suddenly\n> switch.\n\nI share the latter two of the above three. I was giving distro\npackagers a bit more credit for their diligence in knowing what they\nare packaging than you seem to be in your first point, but I admit\nthat it is a blind faith.\n\n> But that being said, this is Felipe's code. While we have a legal right\n> to distribute it in v2.0, if he would really prefer it out for v2.0, I\n> would respect that.\n\nI am fine with that.\n\n> I would prefer to instrument the code with warnings, as that is the sort\n> of thing a packager moving from -rc3 to -final might not notice, and\n> shipping the warnings to end users who did not package the software in\n> the first place will not help them. It is the attention of the packagers\n> (and source-builders) you want to get.\n\nI do agree that a new warning every time it is run will be a more\nlikely to grab users' attention. The conclusion I draw from that\nshared observation is that the user will be annoyed all the time,\nwithout having a power to do anything about the annoyance, until the\nreport s/he (or other users) Throw at the packager, even when the\nversion that was packaged hasn't diverged that much yet, which does\nnot help end users.\n\nI guess the ideal we want is to make sure their build break. What\nif we do the README in addition to rename contrib/remote-helpers to\ncontrib/obsolete-remote-helpers (or s/obsolete/graduated/)? It will\ngive the packagers three choices and I think it hurts people much\nless.\n\n * The packagers that dump the entirety of contrib/ to somewhere\n without doing anything to expose the scripts to user's PATH do\n not have to do anything. The users who chose to pick them up\n from there notice the missing contrib/remote-helpers, notice\n \"obsolete\" (or \"graduated\"), and read README.\n\n * The packagers that pick up from contrib/remote-helpers and\n arrange the scripts to be on user's PATH will find their build\n broken, because they are no longer where they expect them to be.\n They will notice \"obsolete\"(or \"graduated\"), and read README.\n\n - They can choose to pick them up from \"obsolete\", perhaps for\n expediency, perhaps for their change aversion, but that will\n not last once we grabbed their attention, and they will switch\n their upstream in some later release once such a choice makes\n them feel dirty enough.\n\n - They can choose to switch their upstream right now in response\n to the breakage.\n\nI would say that the options I see are these three, and I would rank\nthe \"warn every time\" as less helpful to end-users:\n\n - rename contrib/remote-helpers to contrib/obsolete-remote-helpers\n and add README to point at the upstream.\n\n - remove contrib/remote-helpers scripts and add README.\n\n - warn every time the user runs the scripts.\n\nOr am I reacting to a typo and you meant to say \"I would prefer not\nto instrument\"? Your \"shipping the warnings to end users who did\nnot package the software will not help\" was unclear if you meant the\nREADME that has warning or warning message they have to see every\ntime from the instrumented code.\n"},{"id":"241982","messageId":"CAPc5daWXdt5TMCxj_zSY6uwz5ndjism6HGbzQ8UxstO79z94OA@mail.gmail.com","threadId":"36671","inReplyTo":"20140516084126.GB21468@sigill.intra.peff.net","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-16T18:07:51Z","receivedAt":"2014-05-16T18:07:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"(Sorry if you receive a dup; pobox.com seems to be constipated right now).\n\nJeff King writes:\n\n> On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote:\n>\n>> Two announcements for their version 0.2 on the list archive are not\n>> quite enough to advertise them to their users.\n>\n> I do not think this README nor a mention in the release notes will get\n> their attention either, and many people (and packagers) will continue to\n> use the stale versions forever until those versions go away.\n>\n> I would much rather _replace_ them with a README in the long run, and\n> people will notice that they are gone, and then use the README to update\n> their install procedure.\n>\n> For 2.0, I am hesitant to do that, though I do not have a problem with a\n> README like this as a heads-up to prepare packagers for the future. I\n> say hesitant because people may have been test-packaging 2.0.0-rc3 in\n> preparation for release, and it will be annoying to them to suddenly\n> switch.\n\nI share the latter two of the above three. I was giving distro\npackagers a bit more credit for their diligence in knowing what they\nare packaging than you seem to be in your first point, but I admit\nthat it is a blind faith.\n\n> But that being said, this is Felipe's code. While we have a legal right\n> to distribute it in v2.0, if he would really prefer it out for v2.0, I\n> would respect that.\n\nI am fine with that.\n\n> I would prefer to instrument the code with warnings, as that is the sort\n> of thing a packager moving from -rc3 to -final might not notice, and\n> shipping the warnings to end users who did not package the software in\n> the first place will not help them. It is the attention of the packagers\n> (and source-builders) you want to get.\n\nI do agree that a new warning every time it is run will be a more\nlikely to grab users' attention. The conclusion I draw from that\nshared observation is that the user will be annoyed all the time,\nwithout having a power to do anything about the annoyance, until the\nreport s/he (or other users) Throw at the packager, even when the\nversion that was packaged hasn't diverged that much yet, which does\nnot help end users.\n\nI guess the ideal we want is to make sure their build break. What\nif we do the README in addition to rename contrib/remote-helpers to\ncontrib/obsolete-remote-helpers (or s/obsolete/graduated/)? It will\ngive the packagers three choices and I think it hurts people much\nless.\n\n * The packagers that dump the entirety of contrib/ to somewhere\n without doing anything to expose the scripts to user's PATH do\n not have to do anything. The users who chose to pick them up\n from there notice the missing contrib/remote-helpers, notice\n \"obsolete\" (or \"graduated\"), and read README.\n\n * The packagers that pick up from contrib/remote-helpers and\n arrange the scripts to be on user's PATH will find their build\n broken, because they are no longer where they expect them to be.\n They will notice \"obsolete\"(or \"graduated\"), and read README.\n\n - They can choose to pick them up from \"obsolete\", perhaps for\n expediency, perhaps for their change aversion, but that will\n not last once we grabbed their attention, and they will switch\n their upstream in some later release once such a choice makes\n them feel dirty enough.\n\n - They can choose to switch their upstream right now in response\n to the breakage.\n\nI would say that the options I see are these three, and I would rank\nthe \"warn every time\" as less helpful to end-users:\n\n - rename contrib/remote-helpers to contrib/obsolete-remote-helpers\n and add README to point at the upstream.\n\n - remove contrib/remote-helpers scripts and add README.\n\n - warn every time the user runs the scripts.\n\nOr am I reacting to a typo and you meant to say \"I would prefer not\nto instrument\"? Your \"shipping the warnings to end users who did\nnot package the software will not help\" was unclear if you meant the\nREADME that has warning or warning message they have to see every\ntime from the instrumented code.\n"},{"id":"242007","messageId":"537693aee4fdd_3e4812032fcc@nysa.notmuch","threadId":"36671","inReplyTo":"xmqq8uq1br9c.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-16T22:39:42Z","receivedAt":"2014-05-16T22:39:42Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > On Thu, May 15, 2014 at 03:56:29PM -0700, Junio C Hamano wrote:\n> >\n> >> Two announcements for their version 0.2 on the list archive are not\n> >> quite enough to advertise them to their users.\n> >\n> > I do not think this README nor a mention in the release notes will get\n> > their attention either, and many people (and packagers) will continue to\n> > use the stale versions forever until those versions go away.\n> >\n> > I would much rather _replace_ them with a README in the long run, and\n> > people will notice that they are gone, and then use the README to update\n> > their install procedure.\n> >\n> > For 2.0, I am hesitant to do that, though I do not have a problem with a\n> > README like this as a heads-up to prepare packagers for the future. I\n> > say hesitant because people may have been test-packaging 2.0.0-rc3 in\n> > preparation for release, and it will be annoying to them to suddenly\n> > switch.\n> \n> I share the latter two of the above three. I was giving distro\n> packagers a bit more credit for their diligence in knowing what they\n> are packaging than you seem to be in your first point, but I admit\n> that it is a blind faith.\n\nI don't see why anybody would think otherwise. There are dozens of tools\nin contrib/ many without documentation, or even a description of that\nwhey do. I bet most Git developers don't know what half of them do (even\na quarter), how are package maintainers supposed to know?\n\nAll the packages I've seen stash everything into /usr/share/git, with a\nfew exceptions, like shell completions.\n\n> > But that being said, this is Felipe's code. While we have a legal right\n> > to distribute it in v2.0, if he would really prefer it out for v2.0, I\n> > would respect that.\n> \n> I am fine with that.\n\nAre you? Because in two of the three options you list below you wouldn't\nbe doing that.\n\n> > I would prefer to instrument the code with warnings, as that is the sort\n> > of thing a packager moving from -rc3 to -final might not notice, and\n> > shipping the warnings to end users who did not package the software in\n> > the first place will not help them. It is the attention of the packagers\n> > (and source-builders) you want to get.\n> \n> I do agree that a new warning every time it is run will be a more\n> likely to grab users' attention. The conclusion I draw from that\n> shared observation is that the user will be annoyed all the time,\n\nThat's exactly what we do when anything gets deprecated. Try running Git\nwith an empty configuration for a day and you'll see tons of warnings,\noften huge ones every time the user does common operations, like\n`git push`.\n\nWhy is it OK to warn about minor behavior changes, but not when the\nwhole code the user is exercising might be broken?\n\nAt least the warning I proposed for the remote-helpers is small and to\nthe point, unlike the warning of `git push` without refspec.\n\n> without having a power to do anything about the annoyance, until the\n> report s/he (or other users) Throw at the packager, even when the\n> version that was packaged hasn't diverged that much yet, which does\n> not help end users.\n\nWhat do you expect the packagers are going to do? They will simply\nignore the report as it's not related to their package (git).\n\nI suspect this will continue for quite some time, and very likely these\nwill not be packaged as part of the official distribution, but some\nuser-based repository. In some distributions they might end up being\nunpackaged completely.\n\nTake git-imerge as an example, a very popular tool you yourself are very\nfond of. I don't see it packaged either in ArchLinux, Debian, or Fedora,\nand I don't think it will ever be packaged.\n\nSo, yes, this will hurt our users, that's what every user of an\nout-of-tree tool must suffer, and that's what you unilaterally decided\nusers of git-remote-hg/bzr should suffer.\n\n> I guess the ideal we want is to make sure their build break.\n\nWe cannot make 'cp -r contrib /usr/share/git' fail, that's all packagers\ndo.\n\nI already pointed to the fact that most of the tools in contrib\nshouldn't even be there, and that most of them should have tests. If\nthere was a standardized way to tests contrib, we could make the build\nbreak. But you ignored my call of attention.\n\n> What if we do the README in addition to rename contrib/remote-helpers\n> to contrib/obsolete-remote-helpers (or s/obsolete/graduated/)? It\n> will give the packagers three choices and I think it hurts people much\n> less.\n> \n> * The packagers that dump the entirety of contrib/ to somewhere\n> without doing anything to expose the scripts to user's PATH do\n> not have to do anything. The users who chose to pick them up\n> from there notice the missing contrib/remote-helpers, notice\n> \"obsolete\" (or \"graduated\"), and read README.\n\nThis is wrong. Users will not notice the missing contrib/remote-helpers.\nAt least not initially. If they setup links to /usr/share, they'll just\nsee:\n\n fatal: Unable to find remote helper for 'hg'\n\nThen they'll see the missing helper, read the README, then report the\nproblem to the packagers. Then they might include the obsolete\ndirectory, or they might decide not to.\n\n> * The packagers that pick up from contrib/remote-helpers and\n> arrange the scripts to be on user's PATH will find their build\n> broken, because they are no longer where they expect them to be.\n> They will notice \"obsolete\"(or \"graduated\"), and read README.\n> \n> - They can choose to pick them up from \"obsolete\", perhaps for\n> expediency, perhaps for their change aversion, but that will\n> not last once we grabbed their attention, and they will switch\n> their upstream in some later release once such a choice makes\n> them feel dirty enough.\n> \n> - They can choose to switch their upstream right now in response\n> to the breakage.\n\nThat's not how packaging works.\n\nAsk your friend Jonathan Nieder, the packager of Git for Debian, if he\nwould be interested in maintaining a new git-remote-bzr package. My\nguess is that he wont. Maybe he would, but he can assure you that other\npackages wont.\n\nThe fact of the matter is that users cannot depend on packages any more.\nMaybe they'll be packaged, maybe not. If they are it will take a long\ntime before they do. In the meantime they'll have to manually install\nthem all all out-of-tree tools.\n\n> I would say that the options I see are these three, and I would rank\n> the \"warn every time\" as less helpful to end-users:\n> \n> - rename contrib/remote-helpers to contrib/obsolete-remote-helpers\n> and add README to point at the upstream.\n\nI don't like this. This would only reward lazy packagers, it wouldn't be\nclear to the user what happened at first, and even after they use the\nnew place, they wouldn't be disserviced by that code.\n\n> - remove contrib/remote-helpers scripts and add README.\n\nAgain, the user will still see an unhelpful message at first. I guess it\nwouldn't be as bad as the option 1, but it's not as good as the patch I\nproposed where they are replaced with stubs (plus a README).\n\n> - warn every time the user runs the scripts.\n\nI suggested this, but only as a temporary measure.\n\n\nI am surprised that we are talking about the ways to proceed, and which\nways would affect the users less, and what would be the repercussions.\nIn particular, your obvious disconnection from the way packaging is\ndone, I would venture to say you have never made a package in your life.\nThe fact that you think packagers of git would simply package\ngit-remote-hg/bzr as well is pretty appalling. You should have thought\nabout all this *before* making your stupid decision.\n\n-- \nFelipe Contreras\n"},{"id":"242008","messageId":"20140516225228.GA3988@sigill.intra.peff.net","threadId":"36671","inReplyTo":"xmqq8uq1br9c.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-16T22:52:28Z","receivedAt":"2014-05-16T22:52:28Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 16, 2014 at 09:52:15AM -0700, Junio C Hamano wrote:\n\n> Or am I reacting to a typo and you meant to say \"I would prefer not\n> to instrument\"? Your \"shipping the warnings to end users who did\n> not package the software will not help\" was unclear if you meant the\n> README that has warning or warning message they have to see every\n> time from the instrumented code.\n\nArgh, yes, it is a typo. I had written \"I would prefer _not_ to\ninstrument the code with warnings...\". While reading it back to myself,\nI thought \"using underlining there is too argumentative\", but somehow\nmanaged to delete the whole word rather than simply the \"_\" characters.\nI'm very sorry to have wasted people's time by accidentally making the\nopposite point.\n\nI agree with the line of reasoning you laid out in your email,\nespecially:\n\n> I would say that the options I see are these three, and I would rank\n> the \"warn every time\" as less helpful to end-users:\n> \n> - rename contrib/remote-helpers to contrib/obsolete-remote-helpers\n> and add README to point at the upstream.\n> \n> - remove contrib/remote-helpers scripts and add README.\n> \n> - warn every time the user runs the scripts.\n\nI hadn't thought of the rename idea, and it would address the concerns I\nbrought up. I do think \"obsolete\" is the wrong word, as it sends the\nwrong message. The helpers are not obsolete; it is our _copy_ of them\nthat is.\n\n-Peff\n"},{"id":"242017","messageId":"20140517021117.GA29866@debian","threadId":"36671","inReplyTo":"537693aee4fdd_3e4812032fcc@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-05-17T02:11:17Z","receivedAt":"2014-05-17T02:11:17Z","isPatch":true,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:\n> (...) I would venture to say you have never made a package in your\n> life.\n\nAnd you have, Felipe? Let us see the years of experience you surely have\nin the field.\n\n> The fact that you think packagers of git would simply package\n> git-remote-hg/bzr as well is pretty appalling.\n\nIt's not an outlandish thought, in fact, I'd suggest it as probable -\nprovided that they find the projects to be stable and of high quality.\nYou, or someone else, might have to tap them on the shoulder and play\nnice to _ensure_ they know about them (after all, we all know that\npackagers _never_ read READMEs, do they), but you're capable of that,\nI'm sure.\n"},{"id":"242019","messageId":"5376f27b74d9f_66768eb3048f@nysa.notmuch","threadId":"36671","inReplyTo":"20140517021117.GA29866@debian","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-17T05:24:11Z","receivedAt":"2014-05-17T05:24:11Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:\n> > (...) I would venture to say you have never made a package in your\n> > life.\n> \n> And you have, Felipe? Let us see the years of experience you surely have\n> in the field.\n\nAs a matter of fact, yes I've written many packages, for Debian, Fedora,\nArchLinux, and others. Even Windows installers.\n\nBut that's a red herring. Even if was the worst packager in history,\nthat doesn't make Junio's decision any more correct.\n\n> > The fact that you think packagers of git would simply package\n> > git-remote-hg/bzr as well is pretty appalling.\n> \n> It's not an outlandish thought, in fact, I'd suggest it as probable -\n> provided that they find the projects to be stable and of high quality.\n\nDo you want to bet?\n\n> You, or someone else, might have to tap them on the shoulder and play\n> nice to _ensure_ they know about them (after all, we all know that\n> packagers _never_ read READMEs, do they), but you're capable of that,\n> I'm sure.\n\nIn my experience packagers scratch their own itches, and if\ngit-remote-hg/bzr are not their itch, I don't see why any amount of\nnice poking would make them package them. Some other packager would have\nto do it, not the Git packagers.\n\n-- \nFelipe Contreras\n"},{"id":"242020","messageId":"5376f2ca5c90d_65b915db2f877@nysa.notmuch","threadId":"36671","inReplyTo":"20140516225228.GA3988@sigill.intra.peff.net","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-17T05:25:30Z","receivedAt":"2014-05-17T05:25:30Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n\n> I agree with the line of reasoning you laid out in your email,\n> especially:\n\nWhat a shock.\n\n> > I would say that the options I see are these three, and I would rank\n> > the \"warn every time\" as less helpful to end-users:\n> > \n> > - rename contrib/remote-helpers to contrib/obsolete-remote-helpers\n> > and add README to point at the upstream.\n> > \n> > - remove contrib/remote-helpers scripts and add README.\n> > \n> > - warn every time the user runs the scripts.\n> \n> I hadn't thought of the rename idea, and it would address the concerns I\n> brought up. I do think \"obsolete\" is the wrong word, as it sends the\n> wrong message. The helpers are not obsolete; it is our _copy_ of them\n> that is.\n\nOriginally you said you would respect if I wanted the code out\nfor v2.0, I said I would like it out at some point, not necessarily in\nv2.0. Junio said he was fine with that, but the proposals above don't do\nthat.\n\nNow it seems you are changing your mind and you are OK with the code\nremaining in.\n\nDo what you will, but I already told you what I will do in response.\n\n-- \nFelipe Contreras\n"},{"id":"242021","messageId":"20140517062413.GA13003@sigill.intra.peff.net","threadId":"36671","inReplyTo":"5376f2ca5c90d_65b915db2f877@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-17T06:24:13Z","receivedAt":"2014-05-17T06:24:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 17, 2014 at 12:25:30AM -0500, Felipe Contreras wrote:\n\n> > I agree with the line of reasoning you laid out in your email,\n> > especially:\n> \n> What a shock.\n\nPlease stop with these unproductive and rude comments.\n\n> > I hadn't thought of the rename idea, and it would address the concerns I\n> > brought up. I do think \"obsolete\" is the wrong word, as it sends the\n> > wrong message. The helpers are not obsolete; it is our _copy_ of them\n> > that is.\n> \n> Originally you said you would respect if I wanted the code out\n> for v2.0, I said I would like it out at some point, not necessarily in\n> v2.0. Junio said he was fine with that, but the proposals above don't do\n> that.\n> \n> Now it seems you are changing your mind and you are OK with the code\n> remaining in.\n\nMy concerns were with people not noticing the README. Removing the code\nentirely is the way I thought of to address that. Junio suggested\nanother way, which I would also be fine with. And it seems like a\nfriendlier way than removal to handle it for v2.0, if we are going to\nremove the code entirely post-v2.0.\n\nAs before, if your desire is to have the code out for v2.0, then say so.\nI think we should respect such a request.\n\n-Peff\n"},{"id":"242070","messageId":"5377994fe8dec_7a27d4b30438@nysa.notmuch","threadId":"36671","inReplyTo":"20140517062413.GA13003@sigill.intra.peff.net","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-17T17:15:59Z","receivedAt":"2014-05-17T17:15:59Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Sat, May 17, 2014 at 12:25:30AM -0500, Felipe Contreras wrote:\n> \n> > > I agree with the line of reasoning you laid out in your email,\n> > > especially:\n> > \n> > What a shock.\n> \n> Please stop with these unproductive and rude comments.\n\nI am sorry, but the fact of the matter is that you *always* agree with\nJunio.\n\n> > > I hadn't thought of the rename idea, and it would address the concerns I\n> > > brought up. I do think \"obsolete\" is the wrong word, as it sends the\n> > > wrong message. The helpers are not obsolete; it is our _copy_ of them\n> > > that is.\n> > \n> > Originally you said you would respect if I wanted the code out\n> > for v2.0, I said I would like it out at some point, not necessarily in\n> > v2.0. Junio said he was fine with that, but the proposals above don't do\n> > that.\n> > \n> > Now it seems you are changing your mind and you are OK with the code\n> > remaining in.\n> \n> My concerns were with people not noticing the README. Removing the code\n> entirely is the way I thought of to address that. Junio suggested\n> another way, which I would also be fine with. And it seems like a\n> friendlier way than removal to handle it for v2.0, if we are going to\n> remove the code entirely post-v2.0.\n\nI don't see what is friendlier about this:\n\n % sudo pacman -Syu\n % cd ~/dev/my-hg-repo\n % git fetch\n fatal: Unable to find remote helper for 'hg'\n\nThe users will scratch their heads, wonder what's going on, investigate\nthemselves, and eventually they'll have to decide how to fix the issue\nproperly, and how to report it.\n\nOn the other hand:\n\n % git fetch\n WARNING: git-remote-hg is now maintained independently.\n WARNING: For more information visit https://github.com/felipec/git-remote-hg\n searching for changes\n no changes found\n\nYou think that's less friendly?\n\nIf you think so, I think you are totally biased towards whatever happens\nto be the opinion of one person.\n\n> As before, if your desire is to have the code out for v2.0, then say so.\n> I think we should respect such a request.\n\nAs I said before, I do not wish the code to be removed for v2.0, I would\nlike to have only a warning. Either way, do whatever you want for v2.0,\nit's your users you are hurting.\n\nBut if I do not hear *from Junio* that the code will be removed entirely\npost-v2.0, hopefully replaced with stubs (which is obviously the most\nuser-friendly thing to do), I'll do what I said I'll do.\n\n-- \nFelipe Contreras\n"},{"id":"242077","messageId":"20140518012423.GA31087@debian","threadId":"36671","inReplyTo":"5376f27b74d9f_66768eb3048f@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-05-18T01:24:23Z","receivedAt":"2014-05-18T01:24:23Z","isPatch":true,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"Felipe Contreras wrote:\n> James Denholm wrote:\n> > On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:\n> > > (...) I would venture to say you have never made a package in your\n> > > life.\n> > \n> > And you have, Felipe? Let us see the years of experience you surely have\n> > in the field.\n> \n> As a matter of fact, yes I've written many packages, for Debian, Fedora,\n> ArchLinux, and others. Even Windows installers.\n\nI'd hardly say that a few PKGBUILDs count. I've written some myself, not\nhard to do.\n\nThat said, if I had realised you were going to discuss such a trivial\nthing - _making_ packages rather than _maintaining_ them in a repo - I'd\nhave dismissed your statement as mere idiotic vitriol.\n\nDo you honestly think that Junio has _never made a package?_ Never, on\nany of the systems he's ever touched, run makepkg or debuild or\nwhathaveyou?\n\nI could be wrong here, but I'm fairly sure that Junio is a *nix software\ndeveloper of some kind or another. You know, given that he's the\nmaintainer of git, kinda might be the case. And I really doubt that any\n*nix dev, _anywhere_, could have _any_ sort of success without looking\nsideways once or twice at a package builder, given that pre-release\nhomebrewing of expected packages is only an absolutely critical part of\ntesting.\n\nCome on, man. Don't be silly.\n\n> But that's a red herring. Even if was the worst packager in history,\n> that doesn't make Junio's decision any more correct.\n\nNo, but it would render your bizarre, tantrum-like accusations as\ngenerally baseless. I mean, I don't think anyone actually puts weight on\nthem anyway, but hey, never hurts to shine a spotlight on nonsense.\n\n> > > The fact that you think packagers of git would simply package\n> > > git-remote-hg/bzr as well is pretty appalling.\n> > \n> > It's not an outlandish thought, in fact, I'd suggest it as probable -\n> > provided that they find the projects to be stable and of high quality.\n> \n> Do you want to bet?\n\nNot a betting man. However, ignoring that for a moment, I doubt we'd be\nable to agree on checks and balances for the case where\ngit-remote-hg/bzr were rejected due to the code being of poor quality or\nunstable. So no, I won't bet, because you hold your own work and\nopinions as sacrosanct and infallible.\n\n> > You, or someone else, might have to tap them on the shoulder and play\n> > nice to _ensure_ they know about them (after all, we all know that\n> > packagers _never_ read READMEs, do they), but you're capable of that,\n> > I'm sure.\n> \n> In my experience packagers scratch their own itches, and if\n> git-remote-hg/bzr are not their itch, I don't see why any amount of\n> nice poking would make them package them. Some other packager would have\n> to do it, not the Git packagers.\n\nIf there's a demand, Felipe, and the build process is sane, I can't see\nwhy they wouldn't. Package maintainers are aware they provide a service\nto their distributions. If you really want, poke them _with_ the\nmajority of the necessary work done, hand them the\nPKGBUILDs/whathaveyou yourself. Pre-scratch the itch if you really feel\nthey won't care.\n"},{"id":"242078","messageId":"53781b8df1b63_440ee792f80@nysa.notmuch","threadId":"36671","inReplyTo":"20140518012423.GA31087@debian","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-18T02:31:41Z","receivedAt":"2014-05-18T02:31:41Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> Felipe Contreras wrote:\n> > James Denholm wrote:\n> > > On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:\n> > > > (...) I would venture to say you have never made a package in your\n> > > > life.\n> > > \n> > > And you have, Felipe? Let us see the years of experience you surely have\n> > > in the field.\n> > \n> > As a matter of fact, yes I've written many packages, for Debian, Fedora,\n> > ArchLinux, and others. Even Windows installers.\n> \n> I'd hardly say that a few PKGBUILDs count. I've written some myself, not\n> hard to do.\n\nNot hard, but Junio clearly hasn't done so.\n\n> That said, if I had realised you were going to discuss such a trivial\n> thing - _making_ packages rather than _maintaining_ them in a repo - I'd\n> have dismissed your statement as mere idiotic vitriol.\n\nWhy would anybody write packages and not maintain them? Of course I'm\ntalking about maintaining packages.\n\n> Do you honestly think that Junio has _never made a package?_ Never, on\n> any of the systems he's ever touched, run makepkg or debuild or\n> whathaveyou?\n\nI didn't say _build_ a package, I said _write_ a package. And of course\nI mean a significant package, that other people use, and as such needs\nto have some maintenance.\n\n> I could be wrong here, but I'm fairly sure that Junio is a *nix software\n> developer of some kind or another. You know, given that he's the\n> maintainer of git, kinda might be the case. And I really doubt that any\n> *nix dev, _anywhere_, could have _any_ sort of success without looking\n> sideways once or twice at a package builder, given that pre-release\n> homebrewing of expected packages is only an absolutely critical part of\n> testing.\n> \n> Come on, man. Don't be silly.\n\nYou are the one being silly, looking at a package builder doesn't give\nyou any insight about the way packaging is done in distributions. If\nJunio has or hasn't done so is totally unimportant.\n\nYou are just talking about completely irrelevant stuff, so I'm going to\nignore your points about the matter.\n\n> > But that's a red herring. Even if was the worst packager in history,\n> > that doesn't make Junio's decision any more correct.\n> \n> No, but it would render your bizarre, tantrum-like accusations as\n> generally baseless. I mean, I don't think anyone actually puts weight on\n> them anyway, but hey, never hurts to shine a spotlight on nonsense.\n> \n> > > > The fact that you think packagers of git would simply package\n> > > > git-remote-hg/bzr as well is pretty appalling.\n> > > \n> > > It's not an outlandish thought, in fact, I'd suggest it as probable -\n> > > provided that they find the projects to be stable and of high quality.\n> > \n> > Do you want to bet?\n> \n> Not a betting man. However, ignoring that for a moment, I doubt we'd be\n> able to agree on checks and balances for the case where\n> git-remote-hg/bzr were rejected due to the code being of poor quality or\n> unstable. So no, I won't bet, because you hold your own work and\n> opinions as sacrosanct and infallible.\n\nIt is not poor quality or unstable, Junio said so himself when he\ngraduated them to the core.\n\nI suppose you don't trust Junio's opinion either.\n\n> > > You, or someone else, might have to tap them on the shoulder and play\n> > > nice to _ensure_ they know about them (after all, we all know that\n> > > packagers _never_ read READMEs, do they), but you're capable of that,\n> > > I'm sure.\n> > \n> > In my experience packagers scratch their own itches, and if\n> > git-remote-hg/bzr are not their itch, I don't see why any amount of\n> > nice poking would make them package them. Some other packager would have\n> > to do it, not the Git packagers.\n> \n> If there's a demand, Felipe, and the build process is sane, I can't see\n> why they wouldn't.\n\nYour failure of foresight doesn't change what will actually happen in\nthe future.\n\nMoreover, your argument that follows is a straw man, I argued that the\noriginal maintainer of the \"git\" package wouldn't do the \"git-remote-hg\"\npackage, you didn't address that at all.\n\n-- \nFelipe Contreras\n"},{"id":"242083","messageId":"vpqk39jous5.fsf@anie.imag.fr","threadId":"36671","inReplyTo":"5377994fe8dec_7a27d4b30438@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-05-18T17:34:34Z","receivedAt":"2014-05-18T17:34:34Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> % git fetch\n> WARNING: git-remote-hg is now maintained independently.\n> WARNING: For more information visit https://github.com/felipec/git-remote-hg\n> searching for changes\n> no changes found\n\nI don't think the situation is as simple as you claim. In many cases,\nthe first step before the ones you are mentionning are:\n\n cd $git/contrib/remote-helpers\n cp git-remote-{hg,bzr} somewhere/in/path\n\nThey produces no warning if git-remote-{hg,bzr} exist with the warning,\nbut \"no such file or directory: contrib/remote-helpers\" if the directory\nhas been renamed or removed.\n\nWhen git-remote-{hg,bzr} are installed with a package manager, the fact\nthat they are part of Git's core or not is often irrelevant. For\nexample, Debian splits the git.git source into many packages, so a\nDebian user will not see any difference between helpers included in\ngit.git or outside (e.g. I have to install the package git-svn if I want\nto use git-svn).\n\nThat said, I'm fine with the \"add a warning\" option too.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"242130","messageId":"537938a680272_7b90a792fc4a@nysa.notmuch","threadId":"36671","inReplyTo":"vpqk39jous5.fsf@anie.imag.fr","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-18T22:48:06Z","receivedAt":"2014-05-18T22:48:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Matthieu Moy wrote:\n> Felipe Contreras writes:\n> \n> > % git fetch\n> > WARNING: git-remote-hg is now maintained independently.\n> > WARNING: For more information visit https://github.com/felipec/git-remote-hg\n> > searching for changes\n> > no changes found\n> \n> I don't think the situation is as simple as you claim. In many cases,\n> the first step before the ones you are mentionning are:\n> \n> cd $git/contrib/remote-helpers\n> cp git-remote-{hg,bzr} somewhere/in/path\n\nIn many cases, but not all cases. In other cases they are:\n\n ln -s $git/contrib/remote-helpers/git-remote-hg \\\n somewhere/in/path/git-remote-hg\n\nWhich has to be done only once, and not every time Git is updated.\n\n> They produces no warning if git-remote-{hg,bzr} exist with the warning,\n> but \"no such file or directory: contrib/remote-helpers\" if the directory\n> has been renamed or removed.\n\nSo? They'll get the warning the next time they try to use it, and their\nworkflow won't be interrupted, and the warning will be more useful than\n\"No such file or directory\".\n\n> When git-remote-{hg,bzr} are installed with a package manager, the fact\n> that they are part of Git's core or not is often irrelevant. For\n> example, Debian splits the git.git source into many packages, so a\n> Debian user will not see any difference between helpers included in\n> git.git or outside (e.g. I have to install the package git-svn if I want\n> to use git-svn).\n\nYet there is no git-hg. And I doubt Jonathan Nieder is going to package\nthe out-of-tree git-bzr, which as far as I know, is the only out-of-tree\npackage of these remote helpers in any distro.\n\n-- \nFelipe Contreras\n"},{"id":"242132","messageId":"xmqq7g5i4r48.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"537693aee4fdd_3e4812032fcc@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-18T23:05:58Z","receivedAt":"2014-05-18T23:05:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> > But that being said, this is Felipe's code. While we have a legal right\n>> > to distribute it in v2.0, if he would really prefer it out for v2.0, I\n>> > would respect that.\n>> \n>> I am fine with that.\n>\n> Are you? Because in two of the three options you list below you wouldn't\n> be doing that.\n\n\"that\" does not refer to \"remove them at v2.0 (unconditional)\". It\nrefers to \"If Felipe really wants for the removal for v2.0, I would\nrespect that\". And I saw you said you did not want to disrupt v2.0.\n\nIf the options I listed all meant removal at v2.0, then I would\nunderstand your complaints, but that is not the case, so I am not\nsure what to make of that.\n\n> The fact of the matter is that users cannot depend on packages any more.\n> Maybe they'll be packaged, maybe not. If they are it will take a long\n> time before they do. In the meantime they'll have to manually install\n> them all all out-of-tree tools.\n\nI have always thought that distro packagers are the biggest ally us\nproject leaders have. They locate useful pieces of software,\nmassage them into a shape that fit their distro well and deliver\nwhat we write to their audience. Packaging stuff that are useful to\ntheir end-users is what they do best, and not leaving useful stuff\nunpackaged is in their best interest.\n\nYour statement makes it sound like they are incompetent lazy fools\nwho do not know what is useful for their users.\n\nI find it disturbing to see such a distrust. Or am I being too\nnaive to have too much faith in packaging folks?\n\nI checked the list of packages that depend on \"git\" on one of my\nboxes (it is a bit old Ubuntu). I of course expected that many of\nthem are what comes from our tree split into their own \"niche tool\"\npackages (e.g. git-svn, git-gui, gitweb...), but I was pleasantly\nsurprised to see many that I haven't even aware of being packaged.\nOf course, \"tig\" is among the packages that depend on us which I am\nhappy to see.\n\nThere are things of somewhat questionable value I saw in the list,\nof course. It is already 2014, and I feel fairly safe to feel that\nI can say without offending too many people that I doubt \"git-arch\"\nwould be on such a list of packages distros offer to their users, if\nit were written as a third-party plug-in today.\n\nIt is an (odd) example of a package that is still there mostly by\ninertia at this point, and that inertia comes from many things. It\nis in our tree outside contrib/, it was found useful once in the\npast and was packaged, the packager already has infrastructure to\ncut a separate package out of our tree, and it is more trouble to\nretire it and risk breaking minority users than just keep shipping\nit.\n\nBut hg is not in a situation similar to tla, is it? I simply cannot\nimagine \"there is no history worthwhile to salvage out of Mercurial\nrepositories\" coming anytime in the near future.\n\nAfter looking at the reverse-depends list of packages, my faith is\nstrengthened in that the Git ecosystem is truly maturing and useful\nthird-party plug-ins will be picked up by distro packagers.\n\nAm I delusional?\n"},{"id":"242131","messageId":"xmqq1tvq4r43.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"20140517062413.GA13003@sigill.intra.peff.net","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-18T23:13:31Z","receivedAt":"2014-05-18T23:13:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> My concerns were with people not noticing the README. Removing the code\n> entirely is the way I thought of to address that. Junio suggested\n> another way, which I would also be fine with. And it seems like a\n> friendlier way than removal to handle it for v2.0, if we are going to\n> remove the code entirely post-v2.0.\n>\n> As before, if your desire is to have the code out for v2.0, then say so.\n> I think we should respect such a request.\n\nOK. After thinking about it a bit more, I think renaming the\ndirectory at this point is not a \"clearly superiour\" option and the\njudgment largely depends on your philosophy on transition. Let me\nexplain, backwards from the desired endgame.\n\nI think all of us (including Felipe) agree that in some future time\n[*1*], we won't have either of these two scripts in contrib/, but\njust like contrib/vim, we will leave a README to help those who read\na stale page on the Web that says \"remote-hg in contrib/ is the\nofficially recommended tool to interact with Mercurial\". The README\nwill tell them that they read a stale page that is no longer true,\nand direct them to where they can grab remote-hg/bzr.\n\nWe will need to keep contrib/remote-helpers in that endgame state\nfor quite some time.\n\nIf a user of 1.9.x updates to such an endgame version and then runs\nthe same fetch from Hg, he will not just notice the breakage but is\nforced at that point to go to the GitHub URL and switch, but it may\nnot be a convenient time for him to go through that process. To\nhelp these users, a step that ships the \"stale but working\" scripts\nthat give warning is necessary before the endgame state, and\nFelipe's 77621193 (contrib: remote-helpers: add move warnings\n(v2.0), 2014-05-13) is such a change.\n\nMy suggestion to rename the directory without smudging the scripts\nwas meant to be a step that can come before that step, and I think\nits necessity is debatable. It depends on how gradual a transition\nyou want to give, and being always the more cautious type, I think\nhaving such a step will give packagers who pay attention to what\nthey package and users who pay attention to what they install\nwithout packaging an early chance to notice and prepare.\n\n - The endgame will force the user to update at the point when the\n user needs to use it for his real work, when he may not have time\n for sysadmin. \n\n - The \"always warn\" does not force update at the point of use, but\n it still does not help them to notice well before they try to use\n it for the first time after update;\n\n - \"Break the build\" attempts to help them notice when they try to\n update, not when they need to use the updated one right at this\n moment.\n\nBut I am fine with an expedited transition schedule without the\n\"break the build\" step. That was an optional first step, because\n\"warn but still work\" state we must have before the endgame will\ngive the users the choice of when to adjust anyway.\n\nI also thought about adding an extra step to have even more gradual\ntransition, by the way. A step before the endgame will ship these\nscripts without anything but \"instruct and fail\" (this is not \"warn\nand fail\", as it is too late \"warn\", as the scripts are crippled not\nto work at this point).\n\nThat will still force the user to update at the point when the user\nneeds to use it, but seeing the instruction (e.g. \"run this curl\ncommand to fetch from this URL and store it in a file called\ngit-remote-xx on your $PATH\") that is easy to follow immediately\nwould be better than seeing only a failure (i.e. \"remote-hg not\nfound\"), having to go fish the README, visiting the GitHub pages\nand figuring out how to fetch and install the script, which would\nbe what the user will get with \"README only, no scripts\" endgame.\n\nFor that matter, the warning message given by 77621193, also README\nadded by f000c4e6 (remote-helpers: point at their upstream\nrepositories, 2014-05-15) may want to mention not just the GitHub\nURL for the repository as the whole, but the URL to fetch the latest\nblob with curl/wget, if we really want to help users go back to\ntheir tasks at hand with minimum interruption. I know how to\nconstruct a URL to follow the tip of a specific branch and obtain a\nfull .zip from a GitHub repository, but I do not know offhand if you\ncan do the same for a single blob. If we can come up with one, we\nshould add such a instruction to the warning message and README, as\nthat instruction will be the only thing to help the users in the\nendgame state anyway.\n\nSo to summarize, the following timeline is a full possibility:\n\n 1. (optional) break the build by renaming directory and add\n README. Include not just the repository URL but a blob URL\n and instruction to download via wget/curl.\n\n 2. add warning that is given every time the scripts are run and\n give the same instruction as in README.\n\n 3. (optional) cripple the script to make them always fail after\n showing the same warning as above.\n\n 4. Keep README and retire everything else.\n\nbut I am perfectly fine with dropping these two optional steps and\nfollow an expedited transition of doing 2 and 4.\n\n\n[Footnotes]\n\n*1* Largely of Felipe's choice, and we also agree that that future\n time is not 2.0, as Felipe says he does not want to disrupt the\n upcoming release, and neither do we.\n"},{"id":"242138","messageId":"53795c3e58f73_10da88d30829@nysa.notmuch","threadId":"36671","inReplyTo":"xmqq7g5i4r48.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-19T01:19:58Z","receivedAt":"2014-05-19T01:19:58Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> >> > But that being said, this is Felipe's code. While we have a legal right\n> >> > to distribute it in v2.0, if he would really prefer it out for v2.0, I\n> >> > would respect that.\n> >> \n> >> I am fine with that.\n> >\n> > Are you? Because in two of the three options you list below you wouldn't\n> > be doing that.\n> \n> \"that\" does not refer to \"remove them at v2.0 (unconditional)\". It\n> refers to \"If Felipe really wants for the removal for v2.0, I would\n> respect that\". And I saw you said you did not want to disrupt v2.0.\n> \n> If the options I listed all meant removal at v2.0, then I would\n> understand your complaints, but that is not the case, so I am not\n> sure what to make of that.\n\nIt is a weird choice of semantics then. You said you would \"respect\" my\nwish, but your proposals did not \"follow\" my wish.\n\n> > The fact of the matter is that users cannot depend on packages any more.\n> > Maybe they'll be packaged, maybe not. If they are it will take a long\n> > time before they do. In the meantime they'll have to manually install\n> > them all all out-of-tree tools.\n> \n> I have always thought that distro packagers are the biggest ally us\n> project leaders have. They locate useful pieces of software,\n> massage them into a shape that fit their distro well and deliver\n> what we write to their audience. Packaging stuff that are useful to\n> their end-users is what they do best, and not leaving useful stuff\n> unpackaged is in their best interest.\n\nYet I bet a lot of open-source software is not actually packaged. That's\nthe reason there's Python's pip, and Ruby gems.\n\n*If* your software is popular enough, then yes, packagers are your\nbiggest allys, but if not, they aren't.\n\n> Your statement makes it sound like they are incompetent lazy fools\n> who do not know what is useful for their users.\n\nThis sentence proves you have no idea how packaging is done.\n\nThere is no comittee that hunts down packages that are \"useful for their\nusers\" and assigns available packagers to those projects. Exactly the\nsame way you don't assign Git developers tasks based on what is \"useful\nfor our users\".\n\nEach packager decides what project they package, just like every Git\ndeveloper decides on what feature they work on.\n\nAn obscure package might be packaged because a prominent Debian package\nmaintainer likes it, and a much more useful and popular project might\nnot be packaged simply because no package maintainer is interested in\nit.\n\nExactly the same happens in Git; people work on relatively obsucre\nfeatures such as ref transactions, because they are interested in them,\nand features much more \"useful for our\" users get ignored, because\nthere's nobody (of relevance) championing them.\n\nWhen a popular project that is \"useful for the users\" is neglected for\ntoo long, what usually happens is that an outsider steps up and does the\npackaging, which then goes through a review process, and that outsider\nmight become an official maintainer, and maybe start to package other\nthings too. That's how packagers join the project.\n\nBut nothing gets done if no ousider steps up.\n\nExcatly the same happens in Git; when a feature has been neglected for\ntoo long, an outsider comes and tries to implement it, go through a\nreview process, and eventually start fixing other things too.\n\nSo no, there's no comittee that decides what should be packaged, just\nlike there's no committe that decides what Git features should be\ndeveloped.\n\nIt's incredibly alarming that you would think packagers in open source\ndistributions would work any other way.\n\nAnd it's incredibly funny that you would label people working on such\nmodel as \"incompetent lazy fools\" for \"not knowing what is useful for\ntheir users\", when it is *EXACTLY* the same thing you do in Git; you do\nnot know what is useful for our users; you don't actually care; you just\nwork on whatever you like to work on.\n\nIt's even worst than that, because if somebody steps up to package a\npopular project, the package goes in, but when somebody steps up to\nimplement a feature that improves our user-interface in Git; they get\ntheir knees shot.\n\n> I find it disturbing to see such a distrust. Or am I being too\n> naive to have too much faith in packaging folks?\n\nThere is so much wrong with your mode of thinking and the blindness that\nyou don't see what you yourself do that I don't even know where to\nbegin.\n\nYes you are too naive, on many levels.\n\n> I checked the list of packages that depend on \"git\" on one of my\n> boxes (it is a bit old Ubuntu). I of course expected that many of\n> them are what comes from our tree split into their own \"niche tool\"\n> packages (e.g. git-svn, git-gui, gitweb...), but I was pleasantly\n> surprised to see many that I haven't even aware of being packaged.\n> Of course, \"tig\" is among the packages that depend on us which I am\n> happy to see.\n> \n> There are things of somewhat questionable value I saw in the list,\n> of course. It is already 2014, and I feel fairly safe to feel that\n> I can say without offending too many people that I doubt \"git-arch\"\n> would be on such a list of packages distros offer to their users, if\n> it were written as a third-party plug-in today.\n> \n> It is an (odd) example of a package that is still there mostly by\n> inertia at this point, and that inertia comes from many things. It\n> is in our tree outside contrib/, it was found useful once in the\n> past and was packaged, the packager already has infrastructure to\n> cut a separate package out of our tree, and it is more trouble to\n> retire it and risk breaking minority users than just keep shipping\n> it.\n> \n> But hg is not in a situation similar to tla, is it? I simply cannot\n> imagine \"there is no history worthwhile to salvage out of Mercurial\n> repositories\" coming anytime in the near future.\n> \n> After looking at the reverse-depends list of packages, my faith is\n> strengthened in that the Git ecosystem is truly maturing and useful\n> third-party plug-ins will be picked up by distro packagers.\n\nWhere is git-imerge packaged?\n\nDo you want to bet? Nah, you don't *ever* want to accept you were wrong,\neven you clearly where.\n\n> Am I delusional?\n\nYes you are.\n\nThis is what's going to happen: there won't be an official git-hg\npackage for *years*, if there is ever one. That is my prediction based\non all the available evidence, I am willing to stand by it and accept I\nwas wrong if it proves otherwise.\n\nAre you willing to stand by your own decisions?\n\n-- \nFelipe Contreras\n"},{"id":"242140","messageId":"53795ef8e4023_10da88d30825@nysa.notmuch","threadId":"36671","inReplyTo":"xmqq1tvq4r43.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-19T01:31:36Z","receivedAt":"2014-05-19T01:31:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> My suggestion to rename the directory without smudging the scripts\n> was meant to be a step that can come before that step, and I think\n> its necessity is debatable. It depends on how gradual a transition\n> you want to give, and being always the more cautious type,\n\n> I think having such a step will give packagers who pay attention to\n> what they package and users who pay attention to what they install\n> without packaging an early chance to notice and prepare.\n\nImmaginary packagers.\n\n> - The \"always warn\" does not force update at the point of use, but\n> it still does not help them to notice well before they try to use\n> it for the first time after update;\n\nI don't understand this sentence. They will see a big fat warning every\ntime they run the tool, of course they'll notice.\n\n> - \"Break the build\" attempts to help them notice when they try to\n> update, not when they need to use the updated one right at this\n> moment.\n\nThis cannot be done.\n\n> But I am fine with an expedited transition schedule without the\n> \"break the build\" step. That was an optional first step, because\n> \"warn but still work\" state we must have before the endgame will\n> give the users the choice of when to adjust anyway.\n> \n> I also thought about adding an extra step to have even more gradual\n> transition, by the way. A step before the endgame will ship these\n> scripts without anything but \"instruct and fail\" (this is not \"warn\n> and fail\", as it is too late \"warn\", as the scripts are crippled not\n> to work at this point).\n> \n> That will still force the user to update at the point when the user\n> needs to use it, but seeing the instruction (e.g. \"run this curl\n> command to fetch from this URL and store it in a file called\n> git-remote-xx on your $PATH\") that is easy to follow immediately\n> would be better than seeing only a failure (i.e. \"remote-hg not\n> found\"), having to go fish the README, visiting the GitHub pages\n> and figuring out how to fetch and install the script, which would\n> be what the user will get with \"README only, no scripts\" endgame.\n\nI don't see what's so complicated about this:\n\n WARNING: git-remote-hg is now maintained independently.\n WARNING: For more information visit https://github.com/felipec/git-remote-hg\n\nThey click that URL, and the are immediately greated with this:\n\n To enable this, simply add the git-remote-hg script anywhere in your $PATH:\n\n wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O ~/bin/git-remote-hg\n chmod +x ~/bin/git-remote-hg\n\nClearly you haven't even bothered to visit the home pages of the\nprojects you threw to the wolves.\n\n> So to summarize, the following timeline is a full possibility:\n> \n> 1. (optional) break the build by renaming directory and add\n> README. Include not just the repository URL but a blob URL\n> and instruction to download via wget/curl.\n\nThat won't break the build.\n\n> 2. add warning that is given every time the scripts are run and\n> give the same instruction as in README.\n> \n> 3. (optional) cripple the script to make them always fail after\n> showing the same warning as above.\n\nThis is what I want, and I already sent the patches for; the scripts\nwill be stubs. At this point you would have effectively removed the\ncode, which what I want.\n \n> 4. Keep README and retire everything else.\n\nAfter you've removed the code, I don't care what you do, but I'd say you\nshould remove the stubs after a long period of time.\n\n-- \nFelipe Contreras\n"},{"id":"242142","messageId":"xmqqppja2t8a.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"53795ef8e4023_10da88d30825@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-19T06:11:17Z","receivedAt":"2014-05-19T06:11:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>\n>> - The \"always warn\" does not force update at the point of use, but\n>> it still does not help them to notice well before they try to use\n>> it for the first time after update;\n>\n> I don't understand this sentence. They will see a big fat warning every\n> time they run the tool, of course they'll notice.\n\nLet me ask one question first, in order to avoid miscommunication,\nas I really want to get the first step for v2.0-rc4 in a concrete\nshape tomorrow. Do you think gradual transition worth pursuing or\ndo you think it is a waste of time?\n\nI do not think it matters that much, but since you said you do not\nunderstand...\n\nWhat I meant was that when they update their Git (perhaps at the\nbeginning of the week), the won't know they will now be running\nstale code. The warning comes only when they first run it (perhaps\nat the end of the week) to do some real work with a remote hg\nrepository, which may not be a convenient time to do their sysadmin\ntask. And the next time when they update their Git, they may have\nalready forgotten about the warning. The ideal transition would be\nto somehow let them notice when they are in sysadmin mode.\n\n>> - \"Break the build\" attempts to help them notice when they try to\n>> update, not when they need to use the updated one right at this\n>> moment.\n>\n> This cannot be done.\n\nRenaming the directory will not \"break at the build time\" for those\nwho have already did \"ln -s\" these scripts, of course, but it will\n\"break at the build time\" for others (i.e. those who \"cp\"), no?\nAgain, not very important, as I too consider it optional. If you\nare shooting for an expedited transition, it is perfectly fine to\ndrop it.\n\n> They click that URL, and the are immediately greated with this:\n>\n> To enable this, simply add the git-remote-hg script anywhere in your $PATH:\n>\n> wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O ~/bin/git-remote-hg\n> chmod +x ~/bin/git-remote-hg\n\nPerfect. I did check the page when double-checking the URL while\nwriting the README thing, and I did skim the page, but I must have\nmissed it.\n\nWe could add these two to the warning, then, to discourage people\nwho see \"please visit this URL\" and say \"Yuck, I have no time for\nthat\" without actually visiting.\n\n>> So to summarize, the following timeline is a full possibility:\n>> ...\n>> 2. add warning that is given every time the scripts are run and\n>> give the same instruction as in README.\n>> \n>> 3. (optional) cripple the script to make them always fail after\n>> showing the same warning as above.\n>\n> This is what I want, and I already sent the patches for; the scripts\n> will be stubs. At this point you would have effectively removed the\n> code, which what I want.\n\nI think explained why the step 3 would not help very much compared\nto the \"there is no script, only README remains\" endgame (and that\nis why it is marked as \"optional\"). Actually, you reminded me that\na very short and easy-to-follow instruction is on the page referred\nto from README and the warnings, which means that this step would\nmake even less difference compared to the endgame.\n\nI don't think I saw you explain why that is not the case and why we\ndo want this step (and I cannot quite tell if you are aiming for\nmore gradual transition that wants this step, or an expedited one\nthat does not). I am fine with either way.\n\nIn any case, I'd ask another question to avoid wasting time on\nmiscommunication. By \"This is what I want\", do you mean you want\nthis step 3 also in v2.0, or do you mean you want 2 alone in v2.0\nthen step 3 some time later?\n\nUnless you want 2 and 3 together at v2.0, we do not have to decide\nthe merit of step 3 before v2.0-rc4; if you do want 2 and 3 together\nfor v2.0, then your prompt answer matters a lot.\n\nYou said your \"wish\" wasn't \"respected\" in another message, when I\nexplained that I thought you did not want to disrupt v2.0 by\ninsisting on removing these scripts and that was why I listed\noptions that did not involve removal of the scripts. Are you saying\nthat you wish you want to see them removed or crippled at v2.0?\nChanging your mind after discussion is perfectly fine, by the way.\n\nThanks.\n"},{"id":"242192","messageId":"xmqqegzp1tl7.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"53795ef8e4023_10da88d30825@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-19T19:01:08Z","receivedAt":"2014-05-19T19:01:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>\n>> 2. add warning that is given every time the scripts are run and\n>> give the same instruction as in README.\n>> \n>> 3. (optional) cripple the script to make them always fail after\n>> showing the same warning as above.\n>\n> This is what I want, and I already sent the patches for; the scripts\n> will be stubs. At this point you would have effectively removed the\n> code, which what I want.\n> \n>> 4. Keep README and retire everything else.\n>\n> After you've removed the code, I don't care what you do, but I'd say you\n> should remove the stubs after a long period of time.\n\nLet's try this in a different way, as I sense there is a\nmisunderstanding somewhere about your \"wish\".\n\n>> \"that\" does not refer to \"remove them at v2.0 (unconditional)\". It\n>> refers to \"If Felipe really wants for the removal for v2.0, I would\n>> respect that\". And I saw you said you did not want to disrupt v2.0.\n>> \n>> If the options I listed all meant removal at v2.0, then I would\n>> understand your complaints, but that is not the case, so I am not\n>> sure what to make of that.\n>\n> It is a weird choice of semantics then. You said you would \"respect\" my\n> wish, but your proposals did not \"follow\" my wish.\n\nI understand you do not want to disrupt v2.0. My assumption of that\n\"not disrupting v2.0\" has been \"there still are git-remote-{hg,bzr}\nthat work just like what they had in v1.9.x, perhaps with some\nenhancements and regressions you added in the meantime\", and I\nunderstood Peff's comment \"If Felipe wants the removal\" to mean that\nkind of \"disruption\", i.e. \"there is no git-remote-{hg,bzr} that\nwork.\", which would be either step 3 or 4.\n\nBut your \"After you've removed the code\" comment above makes me\nwonder that perhaps your definition of \"not disrupting\" was\ndifferent from ours (which is not good or bad, just different) and\nyou consider that step 3. is \"removal but not distupting v2.0\"?\n\nIf that is what you want in v2.0, then please say so, and I already\nsaid I am fine with that.\n"},{"id":"242206","messageId":"537a75e0a53b7_afee5d300f3@nysa.notmuch","threadId":"36671","inReplyTo":"xmqqppja2t8a.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-19T21:21:36Z","receivedAt":"2014-05-19T21:21:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Junio C Hamano wrote:\n> >\n> >> - The \"always warn\" does not force update at the point of use, but\n> >> it still does not help them to notice well before they try to use\n> >> it for the first time after update;\n> >\n> > I don't understand this sentence. They will see a big fat warning every\n> > time they run the tool, of course they'll notice.\n> \n> Let me ask one question first, in order to avoid miscommunication,\n> as I really want to get the first step for v2.0-rc4 in a concrete\n> shape tomorrow. Do you think gradual transition worth pursuing or\n> do you think it is a waste of time?\n\nIf by \"gradual transition\" you mean place the contrib/remote-helpers in\nanother directory before removing the code, I do think it's a waste of\ntime, but I don't really care, as long as eventually stubs are put in\nplace.\n\n> I do not think it matters that much, but since you said you do not\n> understand...\n> \n> What I meant was that when they update their Git (perhaps at the\n> beginning of the week), the won't know they will now be running\n> stale code. The warning comes only when they first run it (perhaps\n> at the end of the week) to do some real work with a remote hg\n> repository, which may not be a convenient time to do their sysadmin\n> task. And the next time when they update their Git, they may have\n> already forgotten about the warning. The ideal transition would be\n> to somehow let them notice when they are in sysadmin mode.\n\nYou can add such change in the release notes. Other than that I don't\nsee what we could do.\n\n> >> - \"Break the build\" attempts to help them notice when they try to\n> >> update, not when they need to use the updated one right at this\n> >> moment.\n> >\n> > This cannot be done.\n> \n> Renaming the directory will not \"break at the build time\" for those\n> who have already did \"ln -s\" these scripts, of course, but it will\n> \"break at the build time\" for others (i.e. those who \"cp\"), no?\n\nHow many people copy the scripts every time they update Git? Not many\nI'd gather.\n\n> > They click that URL, and the are immediately greated with this:\n> >\n> > To enable this, simply add the git-remote-hg script anywhere in your $PATH:\n> >\n> > wget https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg -O ~/bin/git-remote-hg\n> > chmod +x ~/bin/git-remote-hg\n> \n> Perfect. I did check the page when double-checking the URL while\n> writing the README thing, and I did skim the page, but I must have\n> missed it.\n> \n> We could add these two to the warning, then, to discourage people\n> who see \"please visit this URL\" and say \"Yuck, I have no time for\n> that\" without actually visiting.\n\nWe could. Personally I don't see the point of making the warning any\nmore annoying. The instructiosn are just one click away, and if they\nhave no time for that, they can just ignore the warning.\n\n> >> So to summarize, the following timeline is a full possibility:\n> >> ...\n> >> 2. add warning that is given every time the scripts are run and\n> >> give the same instruction as in README.\n> >> \n> >> 3. (optional) cripple the script to make them always fail after\n> >> showing the same warning as above.\n> >\n> > This is what I want, and I already sent the patches for; the scripts\n> > will be stubs. At this point you would have effectively removed the\n> > code, which what I want.\n> \n> I think explained why the step 3 would not help very much compared\n> to the \"there is no script, only README remains\" endgame (and that\n> is why it is marked as \"optional\"). Actually, you reminded me that\n> a very short and easy-to-follow instruction is on the page referred\n> to from README and the warnings, which means that this step would\n> make even less difference compared to the endgame.\n> \n> I don't think I saw you explain why that is not the case and why we\n> do want this step (and I cannot quite tell if you are aiming for\n> more gradual transition that wants this step, or an expedited one\n> that does not). I am fine with either way.\n\nTo me the endgame is that the code is removed, and only stubs remain.\nWhat you do after that is up to you.\n\n> In any case, I'd ask another question to avoid wasting time on\n> miscommunication. By \"This is what I want\", do you mean you want\n> this step 3 also in v2.0, or do you mean you want 2 alone in v2.0\n> then step 3 some time later?\n\nI meant I want 3. eventually, hopefully for v2.1.\n\n> You said your \"wish\" wasn't \"respected\" in another message, when I\n> explained that I thought you did not want to disrupt v2.0 by\n> insisting on removing these scripts and that was why I listed\n> options that did not involve removal of the scripts. Are you saying\n> that you wish you want to see them removed or crippled at v2.0?\n> Changing your mind after discussion is perfectly fine, by the way.\n\nYou did not specify those were only for v2.0.\n\nNo, I don't want them crippled for v2.0. A warning should suffice.\n\n-- \nFelipe Contreras\n"},{"id":"242205","messageId":"xmqqha4lwj57.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"53795c3e58f73_10da88d30829@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-19T21:31:00Z","receivedAt":"2014-05-19T21:31:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> \n>> After looking at the reverse-depends list of packages, my faith is\n>> strengthened in that the Git ecosystem is truly maturing and useful\n>> third-party plug-ins will be picked up by distro packagers.\n>\n> Where is git-imerge packaged?\n\nI didn't see it on the archive the said Ubuntu box slurps from, but\nI did not check all the other distros.\n\nMichael, do you know what distro folks are doing with imerge? For\nthe purpose of this thread, \"I do not follow distros, and I do not\nknow\" is a perfectly acceptable answer, but it would be very\nrelevant if your answer is \"I suggested these distros to include it,\nbut so far they have been uncooperative and I haven't had much\nsuccess\".\n\n> Do you want to bet? Nah, you don't *ever* want to accept you were wrong,\n> even you clearly where.\n> ...\n> This is what's going to happen: there won't be an official git-hg\n> package for *years*, if there is ever one. That is my prediction based\n> on all the available evidence, I am willing to stand by it and accept I\n> was wrong if it proves otherwise.\n>\n> Are you willing to stand by your own decisions?\n\nIf I understand correctly, you have made and you do maintain some\npackages and as an insider, you do not have to wait for \"an\noutsider\" to step up to make remote-{hg,bzr} packages yourself. You\nmay already have done so for your own use and told other people\nabout them, and others may have chosen to wait for you to push them\nto distros instead of championing these tools by packaging them\nthemselves.\n\nWhen you have such an influence on the outcome either way of your\nchoice, I do not see much value in such a bet.\n\nI do know enough to agree with you that there may be no committee,\npackagers may scratch their own itches, and a program that is not\nvery useful for the packagers, especially the ones useful only for\nnon-technical niche audiences, may fall through the cracks.\n\nBut I actually think that \"we package what we want to use\" is a good\nthing for programs whose primary audience is the software developer\ntypes. The packagers are part of their audiences [*1*]. Because of\nthat, even if remote-{hg,bzr} do not get packaged for a long time, I\ndoubt that it tells us what you are stipulating. The only thing we\ncan infer would be that these programs did not interest the software\ndeveloper types to motivate them enough, and we wouldn't know why\nthey found the programs uninteresting. It may be because those who\nhave history in Hg prefer to interact with remote Git repositories\nby pushing into and fetching from them using Hg tools than using Git\ntools. It would not indicate \"useful tools fall through the cracks\"\nif it were the case, would it?\n\nIndeed I saw bzr-git that came from the Bazaar land packaged on the\nbox I mentioned, and its description sounded like it is meant to\nwork in such a way that allows Bazaar commits to be pushed to Git\nrepositories using a bzr tool.\n\nBy the way, I also saw git-mediawiki packaged from contrib/ in our\ntree. I found it not very credible to say \"contrib/ is treated as a\nsingle ball of wax without much value by packagers, and we need to\nmove the helpers up to core in order for them to be used more\nwidely\" after seeing that.\n\n\n[Footnotes]\n\n*1* I saw you called them \"wolves\" at least twice recently---where\n does such a distrust come from?\n"},{"id":"242210","messageId":"xmqqzjidv1y4.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"537a75e0a53b7_afee5d300f3@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-19T22:27:47Z","receivedAt":"2014-05-19T22:27:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> We could add these two to the warning, then, to discourage people\n>> who see \"please visit this URL\" and say \"Yuck, I have no time for\n>> that\" without actually visiting.\n>\n> We could. Personally I don't see the point of making the warning any\n> more annoying. The instructiosn are just one click away, and if they\n> have no time for that, they can just ignore the warning.\n\nYes, if they know a short-and-sweet instruction is at the top of the\npage, \"just one click away\" is a good justification, but the reason\nI suggested to add the instruction to the warning is because the URL\nalone does not tell them that there is a short and easy-to-follow\ninstruction is behind it, not giving them enough clue to judge if\nthey have time for that or not.\n\n> To me the endgame is that the code is removed, and only stubs remain.\n> ...\n> I meant I want 3. eventually, hopefully for v2.1.\n> ...\n> No, I don't want them crippled for v2.0. A warning should suffice.\n\nOK, I think I understand what you want, and I am fine with that\ntimeline.\n\nI can start preparing -rc4 now, but it may slip into tomorrow.\n\nThanks.\n"},{"id":"242217","messageId":"xmqqvbt1uzo0.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"xmqqzjidv1y4.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-19T23:17:03Z","receivedAt":"2014-05-19T23:17:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Felipe Contreras writes:\n>\n>> We could. Personally I don't see the point of making the warning any\n>> more annoying....\n\nIf we were giving the users a choice of \"no thanks, I'll keep using\nthe obsolete one\", then trying to be a low key and giving them a way\nto squelch with an advice.* config might make sense, but if we plan\nto remove/stub at as early as v2.1, I think annoyance is very much\nwhat we want, actually, because it clearly is the case that we do\nprefer users switching instead of waiting for v2.1.\n\nHow does this sound?\n\n-- >8 --\nFrom: Junio C Hamano \nDate: Mon, 19 May 2014 16:05:34 -0700\nSubject: [PATCH] remote-helpers: give short instructions to download the\n latest\n\nSigned-off-by: Junio C Hamano \n---\n contrib/remote-helpers/git-remote-bzr | 6 ++++++\n contrib/remote-helpers/git-remote-hg | 6 ++++++\n 2 files changed, 12 insertions(+)\n\ndiff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\nindex be4b9a3..c0cb652 100755\n--- a/contrib/remote-helpers/git-remote-bzr\n+++ b/contrib/remote-helpers/git-remote-bzr\n@@ -46,6 +46,12 @@ import atexit, shutil, hashlib, urlparse, subprocess\n sys.stderr.write('WARNING: git-remote-bzr is now maintained independently.\\n')\n sys.stderr.write('WARNING: For more information visit https://github.com/felipec/git-remote-bzr\\n')\n \n+sys.stderr.write('''WARNING: You can pick a directory on your $PATH and download it, e.g.:\n+WARNING: $ wget -O $HOME/bin/git-remote-bzr \\\\\n+WARNING: https://raw.github.com/felipec/git-remote-bzr/master/git-remote-bzr\n+WARNING: $ chmod +x $HOME/bin/git-remote-bzr\n+''')\n+\n NAME_RE = re.compile('^([^<>]+)')\n AUTHOR_RE = re.compile('^([^<>]+?)? ?[<>]([^<>]*)(?:$|>)')\n EMAIL_RE = re.compile(r'([^ \\t<>]+@[^ \\t<>]+)')\ndiff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg\nindex 989df66..c07d1a5 100755\n--- a/contrib/remote-helpers/git-remote-hg\n+++ b/contrib/remote-helpers/git-remote-hg\n@@ -28,6 +28,12 @@ import time as ptime\n sys.stderr.write('WARNING: git-remote-hg is now maintained independently.\\n')\n sys.stderr.write('WARNING: For more information visit https://github.com/felipec/git-remote-hg\\n')\n \n+sys.stderr.write('''WARNING: You can pick a directory on your $PATH and download it, e.g.:\n+WARNING: $ wget -O $HOME/bin/git-remote-hg \\\\\n+WARNING: https://raw.github.com/felipec/git-remote-hg/master/git-remote-hg\n+WARNING: $ chmod +x $HOME/bin/git-remote-hg\n+''')\n+\n #\n # If you want to see Mercurial revisions as Git commit notes:\n # git config core.notesRef refs/notes/hg\n-- \n2.0.0-rc3-442-ga28c44b\n"},{"id":"242221","messageId":"537ab8a0d1304_2edfa832fc53@nysa.notmuch","threadId":"36671","inReplyTo":"xmqqvbt1uzo0.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-20T02:06:24Z","receivedAt":"2014-05-20T02:06:24Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Felipe Contreras writes:\n> >\n> >> We could. Personally I don't see the point of making the warning any\n> >> more annoying....\n> \n> If we were giving the users a choice of \"no thanks, I'll keep using\n> the obsolete one\", then trying to be a low key and giving them a way\n> to squelch with an advice.* config might make sense, but if we plan\n> to remove/stub at as early as v2.1, I think annoyance is very much\n> what we want, actually, because it clearly is the case that we do\n> prefer users switching instead of waiting for v2.1.\n> \n> How does this sound?\n\nThe patch below assumes the user has ~/bin in his PATH, which might not\nbe the case. Personally I don't see the point of creating extra\nannoyance with instructions that might not work.\n\n-- \nFelipe Contreras\n"},{"id":"242234","messageId":"xmqq4n0l2hq0.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"537ab8a0d1304_2edfa832fc53@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-20T04:32:07Z","receivedAt":"2014-05-20T04:32:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> Junio C Hamano writes:\n>> \n>> > Felipe Contreras writes:\n>> >\n>> >> We could. Personally I don't see the point of making the warning any\n>> >> more annoying....\n>> \n>> If we were giving the users a choice of \"no thanks, I'll keep using\n>> the obsolete one\", then trying to be a low key and giving them a way\n>> to squelch with an advice.* config might make sense, but if we plan\n>> to remove/stub at as early as v2.1, I think annoyance is very much\n>> what we want, actually, because it clearly is the case that we do\n>> prefer users switching instead of waiting for v2.1.\n>> \n>> How does this sound?\n>\n> The patch below assumes the user has ~/bin in his PATH, which might not\n> be the case. Personally I don't see the point of creating extra\n> annoyance with instructions that might not work.\n\nYeah, I would be lying if I said that \"that might not work\" did not\nbother me, but I decided it would be on the good side of the\nborderline (it is better to be concise and slightly wrong than\nultra-verbose and precise). As you may have guessed, they were\nstolen from your earlier message that shows what the site says after\nall ;-)\n\nI will probably tag -rc4 with the patch applied sometime tomorrow.\n"},{"id":"242270","messageId":"537B6CF5.4020808@alum.mit.edu","threadId":"36671","inReplyTo":"xmqqha4lwj57.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-05-20T14:55:49Z","receivedAt":"2014-05-20T14:55:49Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/19/2014 11:31 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n>> Junio C Hamano wrote:\n>>>\n>>> After looking at the reverse-depends list of packages, my faith is\n>>> strengthened in that the Git ecosystem is truly maturing and useful\n>>> third-party plug-ins will be picked up by distro packagers.\n>>\n>> Where is git-imerge packaged?\n> \n> I didn't see it on the archive the said Ubuntu box slurps from, but\n> I did not check all the other distros.\n> \n> Michael, do you know what distro folks are doing with imerge? For\n> the purpose of this thread, \"I do not follow distros, and I do not\n> know\" is a perfectly acceptable answer, but it would be very\n> relevant if your answer is \"I suggested these distros to include it,\n> but so far they have been uncooperative and I haven't had much\n> success\".\n\nI haven't heard of any Linux distros that have git-imerge packages. I\njust searched the package archives for Debian, Fedora, Gentoo, and Arch\nwithout finding it.\n\nOTOH I haven't suggested it to any package maintainers nor done much to\npromote it after the initial flurry of publicity after GitMerge 2013\n(blog posts, talk, and interview on GitMinutes).\n\nOh yeah, there's also this animated GIF here [1] :-)\n\nMichael\n\n[1] https://github.com/blog/1691-michael-haggerty-is-a-githubber\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"242275","messageId":"CALKQrgcdSgZ76hKR35SDxGHYQ_cE3toEXphDVSu99B-pbTsSNQ@mail.gmail.com","threadId":"36671","inReplyTo":"537B6CF5.4020808@alum.mit.edu","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-05-20T15:20:44Z","receivedAt":"2014-05-20T15:20:44Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty wrote:\n> On 05/19/2014 11:31 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>> Where is git-imerge packaged?\n>>\n>> I didn't see it on the archive the said Ubuntu box slurps from, but\n>> I did not check all the other distros.\n>>\n>> Michael, do you know what distro folks are doing with imerge? For\n>> the purpose of this thread, \"I do not follow distros, and I do not\n>> know\" is a perfectly acceptable answer, but it would be very\n>> relevant if your answer is \"I suggested these distros to include it,\n>> but so far they have been uncooperative and I haven't had much\n>> success\".\n>\n> I haven't heard of any Linux distros that have git-imerge packages. I\n> just searched the package archives for Debian, Fedora, Gentoo, and Arch\n> without finding it.\n\nFWIW; someone has made an AUR package (a user-contributed Arch package\nrecipe) for git-imerge:\nhttps://aur.archlinux.org/packages/git-imerge-git/\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"242322","messageId":"537bbd6c1daf_a6f166b308b0@nysa.notmuch","threadId":"36671","inReplyTo":"xmqqegzp1tl7.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-20T20:39:08Z","receivedAt":"2014-05-20T20:39:08Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Junio C Hamano wrote:\n> >\n> >> 2. add warning that is given every time the scripts are run and\n> >> give the same instruction as in README.\n> >> \n> >> 3. (optional) cripple the script to make them always fail after\n> >> showing the same warning as above.\n> >\n> > This is what I want, and I already sent the patches for; the scripts\n> > will be stubs. At this point you would have effectively removed the\n> > code, which what I want.\n> > \n> >> 4. Keep README and retire everything else.\n> >\n> > After you've removed the code, I don't care what you do, but I'd say you\n> > should remove the stubs after a long period of time.\n> \n> Let's try this in a different way, as I sense there is a\n> misunderstanding somewhere about your \"wish\".\n> \n> >> \"that\" does not refer to \"remove them at v2.0 (unconditional)\". It\n> >> refers to \"If Felipe really wants for the removal for v2.0, I would\n> >> respect that\". And I saw you said you did not want to disrupt v2.0.\n> >> \n> >> If the options I listed all meant removal at v2.0, then I would\n> >> understand your complaints, but that is not the case, so I am not\n> >> sure what to make of that.\n> >\n> > It is a weird choice of semantics then. You said you would \"respect\" my\n> > wish, but your proposals did not \"follow\" my wish.\n> \n> I understand you do not want to disrupt v2.0. My assumption of that\n> \"not disrupting v2.0\" has been \"there still are git-remote-{hg,bzr}\n> that work just like what they had in v1.9.x, perhaps with some\n> enhancements and regressions you added in the meantime\", and I\n> understood Peff's comment \"If Felipe wants the removal\" to mean that\n> kind of \"disruption\", i.e. \"there is no git-remote-{hg,bzr} that\n> work.\", which would be either step 3 or 4.\n> \n> But your \"After you've removed the code\" comment above makes me\n> wonder that perhaps your definition of \"not disrupting\" was\n> different from ours (which is not good or bad, just different) and\n> you consider that step 3. is \"removal but not distupting v2.0\"?\n> \n> If that is what you want in v2.0, then please say so, and I already\n> said I am fine with that.\n\nNo, I already said I do not want the code removed from v2.0, that's why\nI sent patches that simply added a warning, and I specifically said\nthose were for 2.0.\n\nHowever, after seeing this commit:\n\n10e1fee (Revert \"Merge branch 'fc/transport-helper-sync-error-fix'\")\n\nWhich is:\n\n 1) Inaccurate\n 2) A lie (*you* broke 2.0, not me)\n 3) A disservice to users\n\nI therefore change my wish for you to remove all the remote helpers code\nand a replace them with stubs (the patches I originally sent for\npost-2.0).\n\nIt was a mistake from me to believe you would do the sensible thing for\n2.0.\n\nSo to make it clear, I now request that you do:\n\n 1) Remove all the code.\n\n Since my patches were removed from the list, here's an updated patch\n that applies on top of 'master'\n\n https://github.com/felipec/git/commits/up/remote/remove\n\n 2) Reapply d508e4a (Merge branch 'fc/transport-helper-sync-error-fix')\n\n Since the code in question is no longer part of v2.0, a \"possible\n regression\" that you aren't even sure of cannot be the rationale to\n revert this code.\n\n Your commit 10e1fee (Revert \"Merge branch\n 'fc/transport-helper-sync-error-fix'\") actively hurts the\n out-of-tree tools, so I'll consider a failure to re-revert a hostile\n action.\n\n 3) Update the release notes to mention these tools have been removed\n\n Additionally, you might want to:\n\n 4) Re-add the following release note:\n\n * \"git push\" via transport-helper interface (e.g. remote-hg) has\n been updated to allow forced ref updates in a way similar to the\n natively supported transports\n\n I don't know why you removed it in the first place. Clearly you pay\n no attention at all to these interfaces.\n\nI expect you to do at the very least 1) and 2).\n\n-- \nFelipe Contreras\n"},{"id":"242324","messageId":"537bc0a8eb91a_a6f166b308d@nysa.notmuch","threadId":"36671","inReplyTo":"xmqqha4lwj57.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-20T20:52:56Z","receivedAt":"2014-05-20T20:52:56Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Junio C Hamano wrote:\n> >> \n> >> After looking at the reverse-depends list of packages, my faith is\n> >> strengthened in that the Git ecosystem is truly maturing and useful\n> >> third-party plug-ins will be picked up by distro packagers.\n> >\n> > Where is git-imerge packaged?\n> \n> I didn't see it on the archive the said Ubuntu box slurps from, but\n> I did not check all the other distros.\n\nI will help you: it's not packaged anywhere.\n\n> > Do you want to bet? Nah, you don't *ever* want to accept you were wrong,\n> > even you clearly where.\n> > ...\n> > This is what's going to happen: there won't be an official git-hg\n> > package for *years*, if there is ever one. That is my prediction based\n> > on all the available evidence, I am willing to stand by it and accept I\n> > was wrong if it proves otherwise.\n> >\n> > Are you willing to stand by your own decisions?\n> \n> If I understand correctly, you have made and you do maintain some\n> packages and as an insider, you do not have to wait for \"an\n> outsider\" to step up to make remote-{hg,bzr} packages yourself.\n\nNo, you do not understand how packaging works. ArchLinux's AUR[1] is a\ncommunity-driven repository, anybody can package anything and put it\nthere. That doesn't mean people can simply do `pacman -S git-remote-hg`,\nfar from it.\n\nIt's a placeholder for *outsiders*, not official package maintainers.\n\nI am an outsider in ArchLinux.\n\n> You may already have done so for your own use and told other people\n> about them, and others may have chosen to wait for you to push them to\n> distros instead of championing these tools by packaging them\n> themselves.\n\nYou clearly haven't tried to package anything for any distro. You can't\njust champion packages for a distribution. You have to go through an\narduous process before becoming an official packager.\n\n> When you have such an influence on the outcome either way of your\n> choice, I do not see much value in such a bet.\n\nIf I champion these packages I would be making you win the bet. Why\nwould I do that?\n\n> But I actually think that \"we package what we want to use\" is a good\n> thing for programs whose primary audience is the software developer\n> types. The packagers are part of their audiences [*1*]. Because of\n> that, even if remote-{hg,bzr} do not get packaged for a long time, I\n> doubt that it tells us what you are stipulating. The only thing we\n> can infer would be that these programs did not interest the software\n> developer types to motivate them enough, and we wouldn't know why\n> they found the programs uninteresting. It may be because those who\n> have history in Hg prefer to interact with remote Git repositories\n> by pushing into and fetching from them using Hg tools than using Git\n> tools. It would not indicate \"useful tools fall through the cracks\"\n> if it were the case, would it?\n\nOr it might mean that the people that would otherwise do that packaging\ninstead simply copy the single file needed manually.\n\n> Indeed I saw bzr-git that came from the Bazaar land packaged on the\n> box I mentioned, and its description sounded like it is meant to\n> work in such a way that allows Bazaar commits to be pushed to Git\n> repositories using a bzr tool.\n> \n> By the way, I also saw git-mediawiki packaged from contrib/ in our\n> tree. I found it not very credible to say \"contrib/ is treated as a\n> single ball of wax without much value by packagers, and we need to\n> move the helpers up to core in order for them to be used more\n> widely\" after seeing that.\n\nYou are misconstruing what I said. I said *most* distributions treat\ncontrib as a ball of wax. And I said there were a few *exceptions* on\nthis ball of wax, like completions. remote-helpers are not part of these\nexceptions (with the exception of git-bzr).\n\n> *1* I saw you called them \"wolves\" at least twice recently---where\n> does such a distrust come from?\n\nIt's a jungle out there, and it's every out-of-tree tool by itself. Most\nof the tools on the contrib/ area would not survive if you throw them to\nthose \"wolves\", and you know it.\n\n[1] https://wiki.archlinux.org/index.php/Arch_User_Repository\n\n-- \nFelipe Contreras\n"},{"id":"242325","messageId":"xmqqy4xwrw8o.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"537bbd6c1daf_a6f166b308b0@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-20T21:11:35Z","receivedAt":"2014-05-20T21:11:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> Let's try this in a different way, as I sense there is a\n>> misunderstanding somewhere about your \"wish\".\n>> ...\n> No, I already said I do not want the code removed from v2.0, that's why\n> I sent patches that simply added a warning, and I specifically said\n> those were for 2.0.\n\nYeah, I think there are mails crossing. I sent that \"different way\"\nway before I read your \"already said\" happened.\n\n> So to make it clear, I now request that you do:\n>\n> 1) Remove all the code.\n>\n> Since my patches were removed from the list, here's an updated patch\n> that applies on top of 'master'\n>\n> https://github.com/felipec/git/commits/up/remote/remove\n\nI'll do that, but just one thing to make sure---do you want the\nhelper to exit with status 0?\n\n> 4) Re-add the following release note:\n>\n> * \"git push\" via transport-helper interface (e.g. remote-hg) has\n> been updated to allow forced ref updates in a way similar to the\n> natively supported transports\n\nI am not sure if this one is consistent with 1), as remote-hg will\nno longer be with the release.\n"},{"id":"242330","messageId":"537bc8ea6ced9_1d08f2d2f8fd@nysa.notmuch","threadId":"36671","inReplyTo":"xmqqy4xwrw8o.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-20T21:28:10Z","receivedAt":"2014-05-20T21:28:10Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> >> Let's try this in a different way, as I sense there is a\n> >> misunderstanding somewhere about your \"wish\".\n> >> ...\n> > No, I already said I do not want the code removed from v2.0, that's why\n> > I sent patches that simply added a warning, and I specifically said\n> > those were for 2.0.\n> \n> Yeah, I think there are mails crossing. I sent that \"different way\"\n> way before I read your \"already said\" happened.\n> \n> > So to make it clear, I now request that you do:\n> >\n> > 1) Remove all the code.\n> >\n> > Since my patches were removed from the list, here's an updated patch\n> > that applies on top of 'master'\n> >\n> > https://github.com/felipec/git/commits/up/remote/remove\n> \n> I'll do that, but just one thing to make sure---do you want the\n> helper to exit with status 0?\n\nIt doesn't matter; if the remote helper doesn't respond to the commands\ntransport-helper exits with 128.\n\n> > 4) Re-add the following release note:\n> >\n> > * \"git push\" via transport-helper interface (e.g. remote-hg) has\n> > been updated to allow forced ref updates in a way similar to the\n> > natively supported transports\n> \n> I am not sure if this one is consistent with 1), as remote-hg will\n> no longer be with the release.\n\nRemove '(e.g. remote-hg)', the rest still applies.\n\n-- \nFelipe Contreras\n"},{"id":"242332","messageId":"537bc9b733534_1d08f2d2f83b@nysa.notmuch","threadId":"36671","inReplyTo":"CALKQrgcdSgZ76hKR35SDxGHYQ_cE3toEXphDVSu99B-pbTsSNQ@mail.gmail.com","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-20T21:31:35Z","receivedAt":"2014-05-20T21:31:35Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Johan Herland wrote:\n> On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty wrote:\n> > On 05/19/2014 11:31 PM, Junio C Hamano wrote:\n> >> Felipe Contreras writes:\n> >>> Where is git-imerge packaged?\n> >>\n> >> I didn't see it on the archive the said Ubuntu box slurps from, but\n> >> I did not check all the other distros.\n> >>\n> >> Michael, do you know what distro folks are doing with imerge? For\n> >> the purpose of this thread, \"I do not follow distros, and I do not\n> >> know\" is a perfectly acceptable answer, but it would be very\n> >> relevant if your answer is \"I suggested these distros to include it,\n> >> but so far they have been uncooperative and I haven't had much\n> >> success\".\n> >\n> > I haven't heard of any Linux distros that have git-imerge packages. I\n> > just searched the package archives for Debian, Fedora, Gentoo, and Arch\n> > without finding it.\n> \n> FWIW; someone has made an AUR package (a user-contributed Arch package\n> recipe) for git-imerge:\n> https://aur.archlinux.org/packages/git-imerge-git/\n\nThat doesn't say much. Anybody can put packages there, and it has a\nsingle vote, which suggests not many people use it (if any).\n\n-- \nFelipe Contreras\n"},{"id":"242333","messageId":"xmqqlhtwrufq.fsf@gitster.dls.corp.google.com","threadId":"36671","inReplyTo":"537bc8ea6ced9_1d08f2d2f8fd@nysa.notmuch","subject":"Re: [PATCH] remote-helpers: point at their upstream repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-20T21:50:33Z","receivedAt":"2014-05-20T21:50:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>> ...\n>> > So to make it clear, I now request that you do:\n>> >\n>> > 1) Remove all the code.\n>> ...\n>> I'll do that, but just one thing to make sure---do you want the\n>> helper to exit with status 0?\n>\n> It doesn't matter; if the remote helper doesn't respond to the commands\n> transport-helper exits with 128.\n\nYou're right.\n\n>> > 4) Re-add the following release note:\n>> >\n>> > * \"git push\" via transport-helper interface (e.g. remote-hg) has\n>> > been updated to allow forced ref updates in a way similar to the\n>> > natively supported transports\n>> \n>> I am not sure if this one is consistent with 1), as remote-hg will\n>> no longer be with the release.\n>\n> Remove '(e.g. remote-hg)', the rest still applies.\n\nTrue enough.\n\nI was already deep in today's -rc4 tagging before this exchange, so\nit may be a while until the result is pushed out, but as far as I\nknow the helpers are now stubs, and README no longer says \"a random\nversion that will go stale is kept here merely for convenience\".\n\nAs additional topics that touch contrib/remote-helpers/ need to be\nreverted from 'next', the final pushout may take longer than usual.\nWe'll see.\n"}]}