{"thread":{"id":"52225","subject":"Should we auto-close PRs on git/git?","startedAt":"2019-11-09T02:00:46Z","lastAt":"2019-11-27T02:37:47Z","messageCount":22,"participants":["Emily Shaffer","Junio C Hamano","Johannes Schindelin","Jeff King","Stephen Smith","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"385822","messageId":"20191109020037.GB60198@google.com","threadId":"52225","inReplyTo":null,"subject":"Should we auto-close PRs on git/git?","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-11-09T02:00:37Z","receivedAt":"2019-11-09T02:00:46Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"Hi all,\n\nIt seems to me that the friendly template text we prefill when someone\nopens a pull request in github.com/git/git isn't being fully appreciated\nby many interested contributors. For some time now, Johannes has been\nslogging through the list to try to narrow it down to folks who are\nstill interested in contributing, and yesterday on #git-devel said he\nwas pretty happy with the progress so far.\n\nBut to me, this seems like a sort of Sisyphean task - more folks will\nwant to make contributions and not read the template text, and we will\nhave more PRs being ignored forever, especially if Johannes decides he\ndoesn't want to shepherd those changes anymore (I would have decided\nthat long ago, in his shoes).\n\nTo that end, I wonder if we should add an Action to automatically close\nPRs on that repo. It looks like https://github.com/dessant/repo-lockdown\nwould do the trick. We could close incoming PRs automatically with a\nkind, maybe more succinct or prescriptive version of the prefill text\nencouraging folks to open the exact same PR against gitgitgadget/git\ninstead.\n\nHere's the prefilled template now:\n\n Thanks for taking the time to contribute to Git! Please be advised\n that the Git community does not use github.com for their\n contributions. Instead, we use a mailing list (git@vger.kernel.org)\n for code submissions, code reviews, and bug reports. Nevertheless, you\n can use GitGitGadget (https://gitgitgadget.github.io/) to conveniently\n send your Pull Requests commits to our mailing list.\n\n Please read the \"guidelines for contributing\" linked above!\n\nMaybe we can close PRs with something like this:\n\n Thank you for taking the time to submit a patch!\n\n However, Git does not accept submissions via GitHub pull requests.\n\n You can open an identical pull request to this one against\n https://github.com/gitgitgadget/git and follow the instructions there\n to submit it to the Git mailing list, where reviews are performed.\n\n If you don't want to subscribe to the mailing list, you can keep an\n eye on your patch at https://public-inbox.org/git, or by watching\n comments on your GitGitGadget pull request.\n\n More info on GitGitGadget: https://gitgitgadget.github.io\n\nI was aiming for \"same message, but firmer\", and \"write down something\nso we have a place to start\". I look forward to the discussion.\n\n - Emily\n\nPS: Today we have 17 PRs open against git/git, and I think all of them\nhave been nudged by dscho in comments to open against GGG instead. Many\nare in a state where dscho is sending a ping every few weeks to see if\nthe committer is interested in following through.\n\nhttps://github.com/git/git/pulls\n"},{"id":"385824","messageId":"xmqqtv7dlkcb.fsf@gitster-ct.c.googlers.com","threadId":"52225","inReplyTo":"20191109020037.GB60198@google.com","subject":"Re: Should we auto-close PRs on git/git?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-09T04:55:32Z","receivedAt":"2019-11-09T04:55:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Emily Shaffer writes:\n\n> It seems to me that the friendly template text we prefill when someone\n> opens a pull request in github.com/git/git isn't being fully appreciated\n> by many interested contributors. For some time now, Johannes has been\n> slogging through the list to try to narrow it down to folks who are\n> still interested in contributing, and yesterday on #git-devel said he\n> was pretty happy with the progress so far.\n>\n> But to me, this seems like a sort of Sisyphean task ...\n\nYeah, I would not stop Dscho if he likes doing so, but it does sound\nlike a waste of talent.\n\n> ... want to make contributions and not read the template text, and we will\n> have more PRs being ignored forever, especially if Johannes decides he\n> doesn't want to shepherd those changes anymore (I would have decided\n> that long ago, in his shoes).\n>\n> To that end, I wonder if we should add an Action to automatically close\n> PRs on that repo.\n> It looks like https://github.com/dessant/repo-lockdown\n> would do the trick.\n\nPersonally, I think that it would not help, it would be a waste of\nour time to set up, and it would be a waste of our attention having\nto worry about giving yet another external read/write access to PRs\nto a third-party tool.\n\nI've looked at those PRs, and noticed that the issues that the ones\nwith unedited prefilled template try to address are mostly those\nthat would cost more to give help polishing the patch into an\nacceptable shape than some of us redo them outselves (more\nclarifications below).\n\nQuite honestly, \"drive-by contribution\" is overrated. Surely it is\nnice if those little typoes and forgotten free()s and off-by-ones\ngot fixed by somebody without taking too much of our attention, and\nit would be nicer if we can help those who started from \"drive-by\"\nstatus eventually grow to full fledged contributors.\n\nBut step back and think about these two a bit.\n\nThose tiny typoes, missing calls to free(), etc. that are low\nhanging fruits tend to be \"bugs\" that have only one obvious way to\n\"fix\", without leaving much room to express the patch in any other\nway. It's not like that they now own the bug and the right to make\na patch to fix it because they found and sent a PR first. If\nsomebody else makes the same fix with patch text that happens to be\nidentical, that is perfectly fine. The _only_ real contribution to\nus made by such a PR is to let us know where such a trivial problem\nresides; once that is identified, anybody would fix it the same way.\n\nIt would be far more effective use of the time of the community to\nmake the same fix by any member who already knows how such a patch\nshould look like, while giving a proper credit for discovering the\nissue.\n\nI can already hear people saying that by investing to educate the\noriginal drive-by contributors (instead of \"stealing\" their patch\nand doing it outselves) would yield a larger value in the longer\nterm, as it could help grow the drive-by contributors into our\ncommunity. I would agree with that argument in principle, but\nI do not think that would apply to the drive-by stuff with unedited\nprefilled template still intact.\n\nThe thing is, I do not think we can expect those who do not even\nbother to read the prefilled template to grow to full fledged\ncontributors. Certainly before they start paying attention to what\nare told to them.\n\nSo, I would certainly not veto auto-closing, but I do not think it\nwould help.\n\nThanks.\n"},{"id":"386036","messageId":"nycvar.QRO.7.76.6.1911121946480.46@tvgsbejvaqbjf.bet","threadId":"52225","inReplyTo":"20191109020037.GB60198@google.com","subject":"Re: Should we auto-close PRs on git/git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-12T19:11:06Z","receivedAt":"2019-11-12T19:11:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Emily,\n\nOn Fri, 8 Nov 2019, Emily Shaffer wrote:\n\n> It seems to me that the friendly template text we prefill when someone\n> opens a pull request in github.com/git/git isn't being fully appreciated\n> by many interested contributors.\n\nThat is probably due to our confusing use of the template as a stop sign\n;-)\n\n> For some time now, Johannes has been slogging through the list to try\n> to narrow it down to folks who are still interested in contributing,\n> and yesterday on #git-devel said he was pretty happy with the progress\n> so far.\n\nI don't mind it, and quite honestly, it does not take a lot of time,\nmost of the time.\n\n> But to me, this seems like a sort of Sisyphean task - more folks will\n> want to make contributions and not read the template text, and we will\n> have more PRs being ignored forever, especially if Johannes decides he\n> doesn't want to shepherd those changes anymore (I would have decided\n> that long ago, in his shoes).\n\nThe PRs are not bad. What is bad is all those comments on commits coming\nin as of recent, some developers thinking that they do not need to\nresearch the best way to reach the Git contributor community and instead\njust assuming that adding comments via GitHub's UI is a valid way.\n\nI should probably refrain from trying to help those developers because\nit makes me very cranky, but I just don't want Git to be an unfriendly\nproject.\n\n> To that end, I wonder if we should add an Action to automatically\n> close PRs on that repo. It looks like\n> https://github.com/dessant/repo-lockdown would do the trick. We could\n> close incoming PRs automatically with a kind, maybe more succinct or\n> prescriptive version of the prefill text encouraging folks to open the\n> exact same PR against gitgitgadget/git instead.\n\nI am rather certain that that would not be a good thing to do.\n\nThere are some people who open git/git PRs solely for the PR builds,\nothers to facilitate code review, and yet others just because it is the\nintuitively obvious way to contribute to Git.\n\nEven some long-running PRs are worth keeping open, e.g. the Plan 9\nsupport (which will just take time), the GET_OID_GENTLY one or the one\nclarifying the documentation of `git submodule update` (which both need\nto wait for a time when the respective contributor is less busy), and\nthe likes.\n\n> Here's the prefilled template now:\n>\n> Thanks for taking the time to contribute to Git! Please be advised\n> that the Git community does not use github.com for their\n> contributions. Instead, we use a mailing list (git@vger.kernel.org)\n> for code submissions, code reviews, and bug reports. Nevertheless, you\n> can use GitGitGadget (https://gitgitgadget.github.io/) to conveniently\n> send your Pull Requests commits to our mailing list.\n>\n> Please read the \"guidelines for contributing\" linked above!\n>\n> Maybe we can close PRs with something like this:\n>\n> Thank you for taking the time to submit a patch!\n>\n> However, Git does not accept submissions via GitHub pull requests.\n>\n> You can open an identical pull request to this one against\n> https://github.com/gitgitgadget/git and follow the instructions there\n> to submit it to the Git mailing list, where reviews are performed.\n>\n> If you don't want to subscribe to the mailing list, you can keep an\n> eye on your patch at https://public-inbox.org/git, or by watching\n> comments on your GitGitGadget pull request.\n>\n> More info on GitGitGadget: https://gitgitgadget.github.io\n>\n> I was aiming for \"same message, but firmer\", and \"write down something\n> so we have a place to start\". I look forward to the discussion.\n>\n> - Emily\n>\n> PS: Today we have 17 PRs open against git/git, and I think all of them\n> have been nudged by dscho in comments to open against GGG instead. Many\n> are in a state where dscho is sending a ping every few weeks to see if\n> the committer is interested in following through.\n>\n> https://github.com/git/git/pulls\n\nThey all have been nudged, sometimes to clean up the patch first, or to\nsuggest that maybe the goal of the PR might not be all that desirable.\n\nSome of the PRs probably can be closed, but as I said, I would like to\nthink of Git as a friendly project, a helpful one, so I want to err in\nfavor of talking to the contributors rather than shutting the door in\ntheir face, so to say.\n\nCiao,\nDscho\n"},{"id":"386076","messageId":"20191113011020.GB20431@sigill.intra.peff.net","threadId":"52225","inReplyTo":"nycvar.QRO.7.76.6.1911121946480.46@tvgsbejvaqbjf.bet","subject":"Re: Should we auto-close PRs on git/git?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-11-13T01:10:20Z","receivedAt":"2019-11-13T01:10:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 12, 2019 at 08:11:06PM +0100, Johannes Schindelin wrote:\n\n> > To that end, I wonder if we should add an Action to automatically\n> > close PRs on that repo. It looks like\n> > https://github.com/dessant/repo-lockdown would do the trick. We could\n> > close incoming PRs automatically with a kind, maybe more succinct or\n> > prescriptive version of the prefill text encouraging folks to open the\n> > exact same PR against gitgitgadget/git instead.\n> \n> I am rather certain that that would not be a good thing to do.\n> \n> There are some people who open git/git PRs solely for the PR builds,\n> others to facilitate code review, and yet others just because it is the\n> intuitively obvious way to contribute to Git.\n\nWe talked a while ago about having GitGitGadget operate on git/git,\nrather than on a separate mirror. That would automatically help at least\none class of PR-opener: people who want their patches to reach the list\nbut didn't realize they should be using gitgitgadget/git.\n\nI don't remember what the technical blockers are for getting that set\nup, but it seems like a strictly nicer outcome than auto-closing their\nPR.\n\n-Peff\n"},{"id":"386096","messageId":"11925817.qcmArAFNWq@thunderbird","threadId":"52225","inReplyTo":"xmqqtv7dlkcb.fsf@gitster-ct.c.googlers.com","subject":"Re: Should we auto-close PRs on git/git?","fromName":"Stephen Smith","fromEmail":"ischis2@cox.net","sentAt":"2019-11-13T05:29:45Z","receivedAt":"2019-11-13T05:36:56Z","isPatch":false,"sender":{"key":"ishchis2@gmail.com","avatar":null},"body":"On Friday, November 8, 2019 9:55:32 PM MST Junio C Hamano wrote:\n> > But to me, this seems like a sort of Sisyphean task ...\n> \n> Yeah, I would not stop Dscho if he likes doing so, but it does sound\n> like a waste of talent.\n> \n\nI contribute when I can for small projects, it looks I could help with some of \nthose sparing Dscho some brain cells.\n\n\n\n\n\n"},{"id":"386108","messageId":"nycvar.QRO.7.76.6.1911131234380.46@tvgsbejvaqbjf.bet","threadId":"52225","inReplyTo":"20191113011020.GB20431@sigill.intra.peff.net","subject":"Re: Should we auto-close PRs on git/git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-13T12:04:35Z","receivedAt":"2019-11-13T12:05:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Tue, 12 Nov 2019, Jeff King wrote:\n\n> On Tue, Nov 12, 2019 at 08:11:06PM +0100, Johannes Schindelin wrote:\n>\n> > > To that end, I wonder if we should add an Action to automatically\n> > > close PRs on that repo. It looks like\n> > > https://github.com/dessant/repo-lockdown would do the trick. We could\n> > > close incoming PRs automatically with a kind, maybe more succinct or\n> > > prescriptive version of the prefill text encouraging folks to open the\n> > > exact same PR against gitgitgadget/git instead.\n> >\n> > I am rather certain that that would not be a good thing to do.\n> >\n> > There are some people who open git/git PRs solely for the PR builds,\n> > others to facilitate code review, and yet others just because it is the\n> > intuitively obvious way to contribute to Git.\n>\n> We talked a while ago about having GitGitGadget operate on git/git,\n> rather than on a separate mirror. That would automatically help at least\n> one class of PR-opener: people who want their patches to reach the list\n> but didn't realize they should be using gitgitgadget/git.\n>\n> I don't remember what the technical blockers are for getting that set\n> up, but it seems like a strictly nicer outcome than auto-closing their\n> PR.\n\nOkay, here are a couple of technical challenges, off the top of my head:\n\n# The permission problem\n\nGitGitGadget needs code write permission on\nhttps://github.com/gitgitgadget/git so that it can push those tags that\ncorrespond to delivered patch series iterations. It also needs\npermission to write to Pull Requests (so that it can comment and add\nlabels).\n\nBut on https://github.com/git/git, Junio offered a strong preference\nfor restricting access so that GitGitGadget cannot just push code. I\ndo agree with this, but there is the complication that we cannot ask\nfor a different permission sets depending on which repository we\ninstall the GitHub App.\n\nI just verified that I cannot add a PR comment on git/git using the\nexisting App (which is installed only on gitgitgadget/git).\n\nPossible workaround: I could register a second GitGitGadget app\n(e.g. gitgitgadget2) and install that on git/git, then use that set of\npermissions to interact with PRs on git/git.\n\nThis, however, will require a change in GitGitGadget's code,\nas it now potentially needs to use either the GitGitGadget App's token\nor the GitGitGadget2's. And for pushing the tags it always needs to use\nthe GitGitGadget's token.\n\nBTW I do not like the name `gitgitgadget2` very much (it suggests an\nupgraded version to me), if you have any ideas, I'm all ears.\n\n# Disentangling the tagging part from the rest\n\nAs I said, GitGitGadget pushes tags to gitgitgadget/git that correspond\nto each sent iteration. This is not only to allow for fetching directly\n(rather than trying to find an appropriate base commit and then applying\nthe patches manually, which I find very tedious) but also for the\nrange-diff for v2 and later.\n\nI would like to keep doing this even when letting GitGitGadget handle\ngit/git's PRs.\n\nTo avoid clashes, I would suggest to invent a new tag format. The\ncurrent one is `pr-//-v`.\nInstead of the prefix `pr-`, we could easily use `git-` and be fine.\n\nHowever, that requires changes in GitGitGadget: so far, the URL prefix\n`https://github.com/gitgitgadget/git/` is pretty hard-coded. In theory,\nit would matter only when fetching the commits that need to be\n`/submit`ed, of course, but that will take some careful analysis right\nthere.\n\n# The Checks\n\nTo have the same nice integration with the GitHub Checks, where you can\neasily see when GitGitGadget is running, and get to the logs, we will\nneed to install a separate CI/PR pipeline.\n\nFor technical reasons, this will have to live in\nhttps://dev.azure.com/gitgitgadget/git/_build, as I want to have only\none available agent for these runs: GitGitGadget is not _really_ able to\nrun concurrently. Neither does it have to. It's not like contributors\ntry to send multiple patch series in parallel. This saves me a lot of\nheadache about locking.\n\n# The commit mappings\n\nOne of the things that irks me the most with the mailing list driven\ndevelopment is that it is super hard to go from mail to commit, or for\nthat matter, from commit to commit: _my_ commit in _my_ PR will have a\ncompletely different hash than Junio's commit in gitster/git. To help\nwith that, GitGitGadget adds \"Checks\" to the commits in the PR that\nlink to the corresponding ones in gitster/git.\n\nThis should still be possible even in git/git, I think, provided that\nthe second App would be equipped with permissions to write those checks.\n\n# The PR labels\n\nWhenever `pu` is updated, GitGitGadget tries to figure out what has been\nmerged where, and add labels `pu`, `next`, `master` or `maint` to the\nPRs, closing the ones that made it to `master`.\n\nThis should be equally possible on git/git, again contingent on the\nappropriate permission.\n\n# Reacting to `/submit`, `/preview`, etc\n\nWe can probably reuse the same Azure Function that we have right now,\nprovided that GitHub Apps can share the same webhook URL with other\nApps.\n\nThat's just the stuff off the top of my head.\n\nTo start with this project, if I had the time, I would probably register\nthat second app, install it on my fork and then pretend that my fork is\ngit/git, and start testing what goes wrong (trying to re-route the mails\naway from the Git mailing list, of course).\n\nNot an easy, nor a small project, I am afraid.\n\nCiao,\nDscho\n"},{"id":"386142","messageId":"20191113210929.GC60198@google.com","threadId":"52225","inReplyTo":"nycvar.QRO.7.76.6.1911121946480.46@tvgsbejvaqbjf.bet","subject":"Re: Should we auto-close PRs on git/git?","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-11-13T21:09:29Z","receivedAt":"2019-11-13T21:09:38Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Tue, Nov 12, 2019 at 08:11:06PM +0100, Johannes Schindelin wrote:\n> Hi Emily,\n> \n> On Fri, 8 Nov 2019, Emily Shaffer wrote:\n> \n> > It seems to me that the friendly template text we prefill when someone\n> > opens a pull request in github.com/git/git isn't being fully appreciated\n> > by many interested contributors.\n> \n> That is probably due to our confusing use of the template as a stop sign\n> ;-)\n> \n> > For some time now, Johannes has been slogging through the list to try\n> > to narrow it down to folks who are still interested in contributing,\n> > and yesterday on #git-devel said he was pretty happy with the progress\n> > so far.\n> \n> I don't mind it, and quite honestly, it does not take a lot of time,\n> most of the time.\n> \n> > But to me, this seems like a sort of Sisyphean task - more folks will\n> > want to make contributions and not read the template text, and we will\n> > have more PRs being ignored forever, especially if Johannes decides he\n> > doesn't want to shepherd those changes anymore (I would have decided\n> > that long ago, in his shoes).\n> \n> The PRs are not bad. What is bad is all those comments on commits coming\n> in as of recent, some developers thinking that they do not need to\n> research the best way to reach the Git contributor community and instead\n> just assuming that adding comments via GitHub's UI is a valid way.\n> \n> I should probably refrain from trying to help those developers because\n> it makes me very cranky, but I just don't want Git to be an unfriendly\n> project.\n\nI guess my concern is this: when I reply to some code review, email,\nwhatever, when I am cranky, it makes me seem unfriendly; when I do so\nwhile wearing a maintainership hat (I maintain another project\nelsewhere) it makes my project seem unfriendly :) Besides, I don't think\nthat anybody wants a contributor to be regularly doing work that makes\nthem cranky.\n\n> > PS: Today we have 17 PRs open against git/git, and I think all of them\n> > have been nudged by dscho in comments to open against GGG instead. Many\n> > are in a state where dscho is sending a ping every few weeks to see if\n> > the committer is interested in following through.\n> >\n> > https://github.com/git/git/pulls\n\n> They all have been nudged, sometimes to clean up the patch first, or to\n> suggest that maybe the goal of the PR might not be all that desirable.\n> \n> Some of the PRs probably can be closed, but as I said, I would like to\n> think of Git as a friendly project, a helpful one, so I want to err in\n> favor of talking to the contributors rather than shutting the door in\n> their face, so to say.\n\nI do agree that meeting a patient human instead of silence is a good\ncontributor experience, and I appreciate all the work you're putting in\nthat direction.\n\n - Emily\n"},{"id":"386174","messageId":"20191114074117.GB17186@sigill.intra.peff.net","threadId":"52225","inReplyTo":"nycvar.QRO.7.76.6.1911131234380.46@tvgsbejvaqbjf.bet","subject":"Re: Should we auto-close PRs on git/git?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-11-14T07:41:17Z","receivedAt":"2019-11-14T07:41:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 13, 2019 at 01:04:35PM +0100, Johannes Schindelin wrote:\n\n> > We talked a while ago about having GitGitGadget operate on git/git,\n> > rather than on a separate mirror. That would automatically help at least\n> > one class of PR-opener: people who want their patches to reach the list\n> > but didn't realize they should be using gitgitgadget/git.\n> >\n> > I don't remember what the technical blockers are for getting that set\n> > up, but it seems like a strictly nicer outcome than auto-closing their\n> > PR.\n> \n> Okay, here are a couple of technical challenges, off the top of my head:\n> [...]\n> Not an easy, nor a small project, I am afraid.\n\nYow. That's a lot more involved than I was hoping for.\n\nThanks for writing it up. Some of the points raised were interesting. I\ndo think we'd want git/git (the repository) to remain read-only if\npossible. If GitHub's permissions model is a limiting factor here, let\nme know and I can try to bring it to the attention of the right people.\n\n-Peff\n"},{"id":"386214","messageId":"nycvar.QRO.7.76.6.1911142354290.46@tvgsbejvaqbjf.bet","threadId":"52225","inReplyTo":"20191114074117.GB17186@sigill.intra.peff.net","subject":"Re: Should we auto-close PRs on git/git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-14T23:03:30Z","receivedAt":"2019-11-14T23:04:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Thu, 14 Nov 2019, Jeff King wrote:\n\n> On Wed, Nov 13, 2019 at 01:04:35PM +0100, Johannes Schindelin wrote:\n>\n> > > We talked a while ago about having GitGitGadget operate on git/git,\n> > > rather than on a separate mirror. That would automatically help at least\n> > > one class of PR-opener: people who want their patches to reach the list\n> > > but didn't realize they should be using gitgitgadget/git.\n> > >\n> > > I don't remember what the technical blockers are for getting that set\n> > > up, but it seems like a strictly nicer outcome than auto-closing their\n> > > PR.\n> >\n> > Okay, here are a couple of technical challenges, off the top of my head:\n> > [...]\n> > Not an easy, nor a small project, I am afraid.\n>\n> Yow. That's a lot more involved than I was hoping for.\n>\n> Thanks for writing it up. Some of the points raised were interesting. I\n> do think we'd want git/git (the repository) to remain read-only if\n> possible.\n\nI guess you're right.\n\nWe should probably try to restrict the permissions as much as possible,\nnot only deny write access to the repository.\n\nFor example, one thing GitGitGadget does is to add these \"Checks\" to the\ncommits of the PRs which contain links to the corresponding commits in\ngitster/git (if any). Those can actually not be removed, there is not\neven any API for that. So it would probably make sense to avoid that in\ngit/git.\n\nThis would mean that the git/git part of GitGitGadget does not install\nthose commit mappings. I guess that's okay, they _are_ kinda hard to\nuse.\n\n> If GitHub's permissions model is a limiting factor here, let me know\n> and I can try to bring it to the attention of the right people.\n\nI actually don't think that my use case fits any sane permission model\n;-) After all, I want the GitHub App to _span_ repositories (even orgs),\nand that's not really the idea of Apps.\n\nAfter sleeping over it, I don't actually think that it is such a bad\nidea to add a second GitHub App with a more limited permission set.\n\nCiao,\nDscho\n"},{"id":"386461","messageId":"nycvar.QRO.7.76.6.1911181930290.46@tvgsbejvaqbjf.bet","threadId":"52225","inReplyTo":"nycvar.QRO.7.76.6.1911142354290.46@tvgsbejvaqbjf.bet","subject":"GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-18T18:37:57Z","receivedAt":"2019-11-18T18:38:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Fri, 15 Nov 2019, Johannes Schindelin wrote:\n\n> On Thu, 14 Nov 2019, Jeff King wrote:\n>\n> > On Wed, Nov 13, 2019 at 01:04:35PM +0100, Johannes Schindelin wrote:\n> >\n> > > > We talked a while ago about having GitGitGadget operate on git/git,\n> > > > rather than on a separate mirror. That would automatically help at least\n> > > > one class of PR-opener: people who want their patches to reach the list\n> > > > but didn't realize they should be using gitgitgadget/git.\n> > > >\n> > > > I don't remember what the technical blockers are for getting that set\n> > > > up, but it seems like a strictly nicer outcome than auto-closing their\n> > > > PR.\n> > >\n> > > Okay, here are a couple of technical challenges, off the top of my head:\n> > > [...]\n> > > Not an easy, nor a small project, I am afraid.\n> >\n> > Yow. That's a lot more involved than I was hoping for.\n\nYeah, it wasn't easy. But then, who does not like a little challenge,\nespecially the challenge to test things outside of production? So here\nis a PR: https://github.com/gitgitgadget/gitgitgadget/pull/148\n\nI trust everybody with even rudimentary Javascript skills to be able to\nprovide useful feedback on that PR.\n\nTo build some confidence in my patches (as you probably know, I do not\ntrust reviews as much as I trust real-life testing, although I do prefer\nto have both) I \"kind of\" activated it on my fork, limited to act only\non comments _I_ made on PRs (and sending only to me instead of the\nlist), and it seems to work all right, so far. I cannot say for sure\nwhether it handles the PR labels correctly, but I guess time will tell,\nand I will fix bugs as quickly as I can.\n\nQuestion is: should I turn this thing on? I.e. install that\nGitGitGadget-Git App on https://github.com/git/git? This would allow\nGitHub users to `/submit` directly from PRs opened in that repository. I\nam sure that there are a few kinks to work out, but I do think that it\nshould not take long to stabilize.\n\n> > Thanks for writing it up. Some of the points raised were interesting. I\n> > do think we'd want git/git (the repository) to remain read-only if\n> > possible.\n>\n> I guess you're right.\n>\n> We should probably try to restrict the permissions as much as possible,\n> not only deny write access to the repository.\n>\n> For example, one thing GitGitGadget does is to add these \"Checks\" to the\n> commits of the PRs which contain links to the corresponding commits in\n> gitster/git (if any). Those can actually not be removed, there is not\n> even any API for that. So it would probably make sense to avoid that in\n> git/git.\n>\n> This would mean that the git/git part of GitGitGadget does not install\n> those commit mappings. I guess that's okay, they _are_ kinda hard to\n> use.\n\nI made it so. The GitGitGadget-Git App only requires write permission to\nadd PR comments and labels, which I think should be okay. It\nspecifically has _no_ permission to push to git/git.\n\n> > If GitHub's permissions model is a limiting factor here, let me know\n> > and I can try to bring it to the attention of the right people.\n>\n> I actually don't think that my use case fits any sane permission model\n> ;-) After all, I want the GitHub App to _span_ repositories (even orgs),\n> and that's not really the idea of Apps.\n>\n> After sleeping over it, I don't actually think that it is such a bad\n> idea to add a second GitHub App with a more limited permission set.\n\nThe name _was_ bad, but I did settle for GitGitGadget-Git in the end.\nNot the most elegant name, but hey, it works so far.\n\nCiao,\nDscho\n"},{"id":"386710","messageId":"20191121105414.GA16238@sigill.intra.peff.net","threadId":"52225","inReplyTo":"nycvar.QRO.7.76.6.1911181930290.46@tvgsbejvaqbjf.bet","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-11-21T10:54:14Z","receivedAt":"2019-11-21T10:54:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 18, 2019 at 07:37:57PM +0100, Johannes Schindelin wrote:\n\n> Yeah, it wasn't easy. But then, who does not like a little challenge,\n> especially the challenge to test things outside of production? So here\n> is a PR: https://github.com/gitgitgadget/gitgitgadget/pull/148\n> \n> I trust everybody with even rudimentary Javascript skills to be able to\n> provide useful feedback on that PR.\n\nWow, thanks for working on this! I don't know that I'd call my\njavascript skills even rudimentary, but I did give it a look. The real\nchallenge to me is not the individual lines of code, but understanding\nhow the Azure Pipelines and GitHub App systems fit together. So I didn't\nsee anything wrong, but I also know very little about those systems.\n\nLikewise, the explanations in your comments and commit messages all made\nsense to me. But that may also be a false sense of security. You nicely\nled me through reading the patches, but the likely bug would probably be\none you did not even anticipate. ;)\n\n> To build some confidence in my patches (as you probably know, I do not\n> trust reviews as much as I trust real-life testing, although I do prefer\n> to have both) I \"kind of\" activated it on my fork, limited to act only\n> on comments _I_ made on PRs (and sending only to me instead of the\n> list), and it seems to work all right, so far. I cannot say for sure\n> whether it handles the PR labels correctly, but I guess time will tell,\n> and I will fix bugs as quickly as I can.\n\nYeah, that makes sense to me. Going from one repo to three is not much\nworse than going to two, so it's good to have a testing area, too.\n\nDo you want any third-party testing there (e.g., a user who isn't you\nmaking a PR against dscho/git)?\n\n> Question is: should I turn this thing on? I.e. install that\n> GitGitGadget-Git App on https://github.com/git/git? This would allow\n> GitHub users to `/submit` directly from PRs opened in that repository. I\n> am sure that there are a few kinks to work out, but I do think that it\n> should not take long to stabilize.\n\nI'd say \"yes\". The status quo is probably worse than a system with a few\nbugs. The worst case if it's disastrously wasting submitter's time is\nthat we turn it back off, but I have faith that you'd just fix the bugs\nbefore then anyway.\n\nIs the existing Pipelines integration enough for you to turn it on for\ngit/git, or do I need to tweak any settings?\n\n-Peff\n"},{"id":"386824","messageId":"nycvar.QRO.7.76.6.1911221430510.31080@tvgsbejvaqbjf.bet","threadId":"52225","inReplyTo":"20191121105414.GA16238@sigill.intra.peff.net","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-22T13:50:05Z","receivedAt":"2019-11-22T13:50:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Thu, 21 Nov 2019, Jeff King wrote:\n\n> On Mon, Nov 18, 2019 at 07:37:57PM +0100, Johannes Schindelin wrote:\n>\n> > Yeah, it wasn't easy. But then, who does not like a little challenge,\n> > especially the challenge to test things outside of production? So here\n> > is a PR: https://github.com/gitgitgadget/gitgitgadget/pull/148\n> >\n> > I trust everybody with even rudimentary Javascript skills to be able\n> > to provide useful feedback on that PR.\n>\n> Wow, thanks for working on this! I don't know that I'd call my\n> javascript skills even rudimentary, but I did give it a look. The real\n> challenge to me is not the individual lines of code, but understanding\n> how the Azure Pipelines and GitHub App systems fit together. So I didn't\n> see anything wrong, but I also know very little about those systems.\n\nI actually spent some quality time with the wiki in the past days to\nremedy that. You can adore the result in all its beauty here:\n\nhttps://github.com/gitgitgadget/gitgitgadget/wiki/GitGitGadget's-Azure-Function-and-Azure-Pipelines\n\n> Likewise, the explanations in your comments and commit messages all made\n> sense to me. But that may also be a false sense of security. You nicely\n> led me through reading the patches, but the likely bug would probably be\n> one you did not even anticipate. ;)\n\nRight, but it does help to have somebody cross-check the ideas.\n\nYou probably also realized that Chris Webster and Danh looked over them\nand provided useful suggestions, which I incorporated. One of those\nsuggestions was to document the involved Azure Pipelines ;-)\n\n> > To build some confidence in my patches (as you probably know, I do not\n> > trust reviews as much as I trust real-life testing, although I do\n> > prefer to have both) I \"kind of\" activated it on my fork, limited to\n> > act only on comments _I_ made on PRs (and sending only to me instead\n> > of the list), and it seems to work all right, so far. I cannot say for\n> > sure whether it handles the PR labels correctly, but I guess time will\n> > tell, and I will fix bugs as quickly as I can.\n>\n> Yeah, that makes sense to me. Going from one repo to three is not much\n> worse than going to two, so it's good to have a testing area, too.\n>\n> Do you want any third-party testing there (e.g., a user who isn't you\n> making a PR against dscho/git)?\n\nWhile that would be nice, my fork is a mess and not really set up to\nprovide any useful target branch...\n\nThe real proof of the concept will come when the first git/git PR will be\nsubmitted.\n\n> > Question is: should I turn this thing on? I.e. install that\n> > GitGitGadget-Git App on https://github.com/git/git? This would allow\n> > GitHub users to `/submit` directly from PRs opened in that repository. I\n> > am sure that there are a few kinks to work out, but I do think that it\n> > should not take long to stabilize.\n>\n> I'd say \"yes\". The status quo is probably worse than a system with a few\n> bugs. The worst case if it's disastrously wasting submitter's time is\n> that we turn it back off, but I have faith that you'd just fix the bugs\n> before then anyway.\n\nYes, I hope to be quick enough to fix things.\n\n> Is the existing Pipelines integration enough for you to turn it on for\n> git/git, or do I need to tweak any settings?\n\nAll I need is to install the app:\n\n\tInstall GitGitGadget-Git\n\n\tInstall on your organization Git @git\n\tAll repositories\n\n\tThis applies to all current and future repositories.\n\tOnly select repositories\n\tSelected 1 repository.\n\tgit/git\n\n\t...with these permissions:\n\n\tRead access to code\n\tRead access to checks and metadata\n\tRead and write access to issues and pull requests\n\n... which I just did.\n\nThanks,\nDscho\n"},{"id":"386830","messageId":"nycvar.QRO.7.76.6.1911221542511.31080@tvgsbejvaqbjf.bet","threadId":"52225","inReplyTo":"nycvar.QRO.7.76.6.1911221430510.31080@tvgsbejvaqbjf.bet","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-22T14:43:31Z","receivedAt":"2019-11-22T14:43:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Fri, 22 Nov 2019, Johannes Schindelin wrote:\n\n> On Thu, 21 Nov 2019, Jeff King wrote:\n>\n> > On Mon, Nov 18, 2019 at 07:37:57PM +0100, Johannes Schindelin wrote:\n> >\n> > > To build some confidence in my patches (as you probably know, I do\n> > > not trust reviews as much as I trust real-life testing, although I\n> > > do prefer to have both) I \"kind of\" activated it on my fork, limited\n> > > to act only on comments _I_ made on PRs (and sending only to me\n> > > instead of the list), and it seems to work all right, so far. I\n> > > cannot say for sure whether it handles the PR labels correctly, but\n> > > I guess time will tell, and I will fix bugs as quickly as I can.\n> >\n> > Yeah, that makes sense to me. Going from one repo to three is not much\n> > worse than going to two, so it's good to have a testing area, too.\n> >\n> > Do you want any third-party testing there (e.g., a user who isn't you\n> > making a PR against dscho/git)?\n>\n> While that would be nice, my fork is a mess and not really set up to\n> provide any useful target branch...\n>\n> The real proof of the concept will come when the first git/git PR will\n> be submitted.\n\nSeems to have worked:\nhttps://public-inbox.org/git/pull.670.git.git.1574433665.gitgitgadget@gmail.com/\n\nCiao,\nDscho\n"},{"id":"386996","messageId":"20191125143023.GF494@sigill.intra.peff.net","threadId":"52225","inReplyTo":"nycvar.QRO.7.76.6.1911221430510.31080@tvgsbejvaqbjf.bet","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-11-25T14:30:23Z","receivedAt":"2019-11-25T14:30:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 22, 2019 at 02:50:05PM +0100, Johannes Schindelin wrote:\n\n> > Wow, thanks for working on this! I don't know that I'd call my\n> > javascript skills even rudimentary, but I did give it a look. The real\n> > challenge to me is not the individual lines of code, but understanding\n> > how the Azure Pipelines and GitHub App systems fit together. So I didn't\n> > see anything wrong, but I also know very little about those systems.\n> \n> I actually spent some quality time with the wiki in the past days to\n> remedy that. You can adore the result in all its beauty here:\n> \n> https://github.com/gitgitgadget/gitgitgadget/wiki/GitGitGadget's-Azure-Function-and-Azure-Pipelines\n\nThanks, this was very informative. I have a feeling that some of this\ncould be done via the new Actions stuff that GitHub has been shipping,\nbut I have no idea if it would make any of it easier (and certainly I'm\nnot advocating dropping a working system to chase a new shiny toy).\n\n> All I need is to install the app:\n> [...]\n> ... which I just did.\n\nVery cool. :)\n\n-Peff\n"},{"id":"387107","messageId":"nycvar.QRO.7.76.6.1911262151590.31080@tvgsbejvaqbjf.bet","threadId":"52225","inReplyTo":"20191125143023.GF494@sigill.intra.peff.net","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-26T20:55:54Z","receivedAt":"2019-11-26T20:56:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Mon, 25 Nov 2019, Jeff King wrote:\n\n> On Fri, Nov 22, 2019 at 02:50:05PM +0100, Johannes Schindelin wrote:\n>\n> > > Wow, thanks for working on this! I don't know that I'd call my\n> > > javascript skills even rudimentary, but I did give it a look. The real\n> > > challenge to me is not the individual lines of code, but understanding\n> > > how the Azure Pipelines and GitHub App systems fit together. So I didn't\n> > > see anything wrong, but I also know very little about those systems.\n> >\n> > I actually spent some quality time with the wiki in the past days to\n> > remedy that. You can adore the result in all its beauty here:\n> >\n> > https://github.com/gitgitgadget/gitgitgadget/wiki/GitGitGadget's-Azure-Function-and-Azure-Pipelines\n>\n> Thanks, this was very informative. I have a feeling that some of this\n> could be done via the new Actions stuff that GitHub has been shipping,\n> but I have no idea if it would make any of it easier (and certainly I'm\n> not advocating dropping a working system to chase a new shiny toy).\n\nIt is tempting all right.\n\nThe biggest obstacle is that at least one of those Pipelines requires\naccess to a clone of public-inbox.org/git, and cloning that is rather\nexpensive. Even a shallow fetch would be super expensive, by virtue of\n_all_ the mails being blobs reachable from the tip commit's tree.\n\nFurther, GitHub Actions' triggers are a bit too limited: I want this\nPipeline to trigger when public-inbox.org/git is updated, not when any\nbranch in gitgitgadget/git is updated.\n\nSo yes, while it is tempting, it is also not possible right now to use\nGitHub Actions.\n\nCiao,\nDscho\n"},{"id":"387111","messageId":"20191126215648.GA18872@dcvr","threadId":"52225","inReplyTo":"nycvar.QRO.7.76.6.1911262151590.31080@tvgsbejvaqbjf.bet","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2019-11-26T21:56:48Z","receivedAt":"2019-11-26T21:56:50Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> The biggest obstacle is that at least one of those Pipelines requires\n> access to a clone of public-inbox.org/git, and cloning that is rather\n> expensive. Even a shallow fetch would be super expensive, by virtue of\n> _all_ the mails being blobs reachable from the tip commit's tree.\n\nFwiw, lore.kernel.org/git/$EPOCH.git ought to be somewhat cheaper,\nbut it's a different (more scalable) format which requires SQLite:\n\n\thttps://public-inbox.org/public-inbox-v2-format.html\n\nhttps://lore.kernel.org/git\n\n(and I'm not going to pay extortionist .org fees to keep\n public-inbox.org when it comes up for renewal in 2023,\n maybe everyone can use Tor .onions by then :> )\n"},{"id":"387114","messageId":"nycvar.QRO.7.76.6.1911262322130.31080@tvgsbejvaqbjf.bet","threadId":"52225","inReplyTo":"20191126215648.GA18872@dcvr","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-26T22:22:46Z","receivedAt":"2019-11-26T22:23:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Eric,\n\nOn Tue, 26 Nov 2019, Eric Wong wrote:\n\n> Johannes Schindelin wrote:\n> > The biggest obstacle is that at least one of those Pipelines requires\n> > access to a clone of public-inbox.org/git, and cloning that is rather\n> > expensive. Even a shallow fetch would be super expensive, by virtue of\n> > _all_ the mails being blobs reachable from the tip commit's tree.\n>\n> Fwiw, lore.kernel.org/git/$EPOCH.git ought to be somewhat cheaper,\n> but it's a different (more scalable) format which requires SQLite:\n>\n> \thttps://public-inbox.org/public-inbox-v2-format.html\n\nIs this incremental? GitGitGadget needs this to be incremental ;-)\n\nCiao,\nDscho\n"},{"id":"387116","messageId":"20191126224044.GA13328@dcvr","threadId":"52225","inReplyTo":"nycvar.QRO.7.76.6.1911262322130.31080@tvgsbejvaqbjf.bet","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2019-11-26T22:40:44Z","receivedAt":"2019-11-26T22:40:47Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> On Tue, 26 Nov 2019, Eric Wong wrote:\n> > Johannes Schindelin wrote:\n> > > The biggest obstacle is that at least one of those Pipelines requires\n> > > access to a clone of public-inbox.org/git, and cloning that is rather\n> > > expensive. Even a shallow fetch would be super expensive, by virtue of\n> > > _all_ the mails being blobs reachable from the tip commit's tree.\n> >\n> > Fwiw, lore.kernel.org/git/$EPOCH.git ought to be somewhat cheaper,\n> > but it's a different (more scalable) format which requires SQLite:\n> >\n> > \thttps://public-inbox.org/public-inbox-v2-format.html\n> \n> Is this incremental? GitGitGadget needs this to be incremental ;-)\n\nIncremental as far as \"git fetch\" goes? Of course :>\nThe \"m\" file is overwritten with every commit, so the tree size\nstays at 1 (tree growth was a major scalability problem in v1).\n"},{"id":"387117","messageId":"nycvar.QRO.7.76.6.1911262350240.31080@tvgsbejvaqbjf.bet","threadId":"52225","inReplyTo":"20191126224044.GA13328@dcvr","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-26T22:52:36Z","receivedAt":"2019-11-26T22:53:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Eric,\n\nOn Tue, 26 Nov 2019, Eric Wong wrote:\n\n> Johannes Schindelin wrote:\n> > On Tue, 26 Nov 2019, Eric Wong wrote:\n> > > Johannes Schindelin wrote:\n> > > > The biggest obstacle is that at least one of those Pipelines requires\n> > > > access to a clone of public-inbox.org/git, and cloning that is rather\n> > > > expensive. Even a shallow fetch would be super expensive, by virtue of\n> > > > _all_ the mails being blobs reachable from the tip commit's tree.\n> > >\n> > > Fwiw, lore.kernel.org/git/$EPOCH.git ought to be somewhat cheaper,\n> > > but it's a different (more scalable) format which requires SQLite:\n> > >\n> > > \thttps://public-inbox.org/public-inbox-v2-format.html\n> >\n> > Is this incremental? GitGitGadget needs this to be incremental ;-)\n>\n> Incremental as far as \"git fetch\" goes? Of course :>\n> The \"m\" file is overwritten with every commit, so the tree size\n> stays at 1 (tree growth was a major scalability problem in v1).\n\nLet me try again:\n\nGitGitGadget \"reads\" the mail via the incremental clone, remembering the\nhash of the latest processed commit. When the Azure Pipeline runs, it\nfirst fetches, and if the commit is still the same, does nothing but exit\nwith success. If the commit is different, it looks at the mails that were\nadded, via `git log -p ..`.\n\nIs that possible with the v2 format?\n\nCiao,\nDscho\n"},{"id":"387119","messageId":"20191126235822.GA19066@dcvr","threadId":"52225","inReplyTo":"nycvar.QRO.7.76.6.1911262350240.31080@tvgsbejvaqbjf.bet","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2019-11-26T23:58:22Z","receivedAt":"2019-11-26T23:58:24Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi Eric,\n> \n> On Tue, 26 Nov 2019, Eric Wong wrote:\n> \n> > Johannes Schindelin wrote:\n> > > On Tue, 26 Nov 2019, Eric Wong wrote:\n> > > > Johannes Schindelin wrote:\n> > > > > The biggest obstacle is that at least one of those Pipelines requires\n> > > > > access to a clone of public-inbox.org/git, and cloning that is rather\n> > > > > expensive. Even a shallow fetch would be super expensive, by virtue of\n> > > > > _all_ the mails being blobs reachable from the tip commit's tree.\n> > > >\n> > > > Fwiw, lore.kernel.org/git/$EPOCH.git ought to be somewhat cheaper,\n> > > > but it's a different (more scalable) format which requires SQLite:\n> > > >\n> > > > \thttps://public-inbox.org/public-inbox-v2-format.html\n> > >\n> > > Is this incremental? GitGitGadget needs this to be incremental ;-)\n> >\n> > Incremental as far as \"git fetch\" goes? Of course :>\n> > The \"m\" file is overwritten with every commit, so the tree size\n> > stays at 1 (tree growth was a major scalability problem in v1).\n> \n> Let me try again:\n> \n> GitGitGadget \"reads\" the mail via the incremental clone, remembering the\n> hash of the latest processed commit. When the Azure Pipeline runs, it\n> first fetches, and if the commit is still the same, does nothing but exit\n> with success. If the commit is different, it looks at the mails that were\n> added, via `git log -p ..`.\n> \n> Is that possible with the v2 format?\n\nOf course, yes. The Xapian and SQLite indexing also works the\nsame way \"git log prev..tip\" and storing the latest commit hash.\n"},{"id":"387120","messageId":"xmqqa78iw0f8.fsf@gitster-ct.c.googlers.com","threadId":"52225","inReplyTo":"20191126215648.GA18872@dcvr","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-27T01:52:27Z","receivedAt":"2019-11-27T01:52:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong writes:\n\n> (and I'm not going to pay extortionist .org fees to keep\n> public-inbox.org when it comes up for renewal in 2023,\n> maybe everyone can use Tor .onions by then :> )\n\nJust on this tangent. Would you be willing to keep the domain and\nkeep the service running, if Git Project Leadership Committee pays\nthe fee out of the funds we keep at Software Freedom Conservancy?\n"},{"id":"387128","messageId":"20191127023745.GA15031@dcvr","threadId":"52225","inReplyTo":"xmqqa78iw0f8.fsf@gitster-ct.c.googlers.com","subject":"Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2019-11-27T02:37:45Z","receivedAt":"2019-11-27T02:37:47Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano wrote:\n> Eric Wong writes:\n> \n> > (and I'm not going to pay extortionist .org fees to keep\n> > public-inbox.org when it comes up for renewal in 2023,\n> > maybe everyone can use Tor .onions by then :> )\n> \n> Just on this tangent. Would you be willing to keep the domain and\n> keep the service running, if Git Project Leadership Committee pays\n> the fee out of the funds we keep at Software Freedom Conservancy?\n\nMaybe... I'm against the *principle* of paying extortionists;\nand I don't think the Git project should encourage them, either.\n\nPromoting + developing a Distributed Hash Table (DHT) for\nMessage-ID (and git OID) lookups to fight against centralization\nwould be a better use of time and funds :>\n\nHowever, if EFF and other .orgs prove effective in keeping\nprices reasonable then that's fine, I guess. I personally\nexpect to be financially worse off in 2023 than I was in 2013\nwhen I bought the domain, so some help there could be nice :)\n\nThe actual cost of running a service is only $20/month in VPS\nhosting. It's a business expense at the moment as I hack on\nthat machine for clients, and I'm trying to make public-inbox\ncheaper and easier to host, too.\n\nBut, https://lore.kernel.org/git/ has professionals behind it\nand is more scalable. It's currently missing syntax\nhighlighting and blob regeneration because that's a PITA to\nconfigure, though...\n"}]}