{"thread":{"id":"52103","subject":"RFC: Moving git-gui development to GitHub","startedAt":"2019-10-23T20:13:21Z","lastAt":"2021-04-22T20:22:50Z","messageCount":20,"participants":["Pratyush Yadav","Junio C Hamano","Birger Skogeng Pedersen","Denton Liu","Elijah Newren","Jakub Narebski","Konstantin Ryabitsev","SZEDER Gábor","Son Luong Ngoc","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"384719","messageId":"20191023201310.thzpxyoeb3ta55dc@yadavpratyush.com","threadId":"52103","inReplyTo":null,"subject":"RFC: Moving git-gui development to GitHub","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-10-23T20:13:10Z","receivedAt":"2019-10-23T20:13:21Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"Hi everyone,\n\nI recently had some discussions with Dscho about whether it is a better \nidea to use GitHub for development instead of email [0]. His argument \nwas that GitHub makes it easier for newcomers to contribute, since more \npeople are familiar with GitHub compared to mailing lists. Also, it is \nsomewhat difficult to set up an email-based workflow.\n\nA pretty good argument. Using GitHub would certainly make one-off \ncontributions easier, and make it easier for newcomers to get involved.\n\nBut I feel like it is equally important to know what is good for the \nlong-term contributors. Since I've been involved with git-gui for a \nrelatively short time, I don't know many long term active contributors. \nThose I know of are in Cc. These are people who have frequently or \nsemi-frequently expressed interest in git-gui development. Of course, \npeople not in Cc are also welcome to express their opinions, and if I \nforgot to put someone in there that I should have, my apologies.\n\nI want to know people's opinion on whether it is a good idea to move \ndevelopment to GitHub.\n\nJust to lay out my views on the subject, here's a list of advantages and \ndisadvantages that I can come up with.\n\nArguments in favor of moving to GitHub:\n\n- Easier for new and one-off contributors.\n\n- Potentially easier for existing contributors. A lot of people are \n  already very comfortable with GitHub's workflow.\n\n- The \"Issues\" section can serve as an issue tracker. Right now, my \n  \"issue tracker\" is my memory and a small text file I have on my disk.\n\n- Rich text capabilities. I'm generally not a big fan of rich text, but \n  Markdown IMO has found a pretty good balance. Also, it would allow \n  people to post images, which is nice since it is a GUI (IIRC, the \n  mailing list strips attachments).\n\n- We reduce the noise on the Git list. Most people subscribed to the \n  list probably don't care about git-gui. So all git-gui related emails \n  are essentially noise for them. And while the volume has been \n  relatively low, it is not negligible.\n\nArguments against moving to GitHub:\n\n- We lose the audience that we have on the mailing list. Every now and \n  then, people who are interested in Git, and not really in git-gui \n  chime in with help and suggestions. Those people are likely to not \n  want to follow the repo on GitHub, so we lose that insight. One \n  example that comes to my mind would be Denton Liu chiming in to help \n  with some commits that were missing from my tree.\n\n- We depend on a non-open proprietary platform. While I personally don't \n  really care that much, some people might. But the truth remains that \n  it is a closed platform that I or any other contributor has no control \n  over. If GitHub decides to ban me or any other contributor tomorrow, \n  we can do nothing about it. This might sound far-fetched, but it has \n  happened recently [1]. This specific case did not touch public repos, \n  but this can change in the future. Something like this is less likely \n  to happen to the Git mailing list and email.\n\n- People are restricted to the workflow prescribed by GitHub. With \n  email, there is a certain degree of flexibility/customizability with \n  how you sort your mail, how you configure your mail client, etc.\n\n- Sub-threads are not supported. Each reply is only to the \"main\" \n  thread, and you can't reply to a reply (like you can do in email). It \n  is a minor thing, but worth a mention IMHO.\n\nThis list is not meant to be exhaustive in any way. The intention is to \nstart listing out the benefits and losses so we can make an informed \ndecision. Please feel free to add to this list (or remove from it).\n\n[0] https://public-inbox.org/git/nycvar.QRO.7.76.6.1910061054470.46@tvgsbejvaqbjf.bet/\n[1] https://www.theverge.com/2019/7/29/8934694/github-us-trade-sanctions-developers-restricted-crimea-cuba-iran-north-korea-syria\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"384739","messageId":"xmqqimoehp7u.fsf@gitster-ct.c.googlers.com","threadId":"52103","inReplyTo":"20191023201310.thzpxyoeb3ta55dc@yadavpratyush.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-10-24T02:06:13Z","receivedAt":"2019-10-24T02:06:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pratyush Yadav <me@yadavpratyush.com> writes:\n\n> Arguments in favor of moving to GitHub:\n>\n> - Easier for new and one-off contributors.\n\nIt is uptimately up to you, the maintainer of the project, but\npersonally I feel \"new and one-off\" are way overvalued, after\nconsidering if it serves the project and its users better to make it\neasier for \"new and one-off\" contributors, or if it serves these\n\"new and one-off\" contributors more than it benefits the project and\nits users.\n\nA quick rule of thumb I use is that it is worth spending my time on\ntraining a new contributor (with hand-holding on workflows,\nconventions, etc.) if it takes less than 3 times of effort compared\nto doing the task myself (if I had infinite amount of time, that is)\nfor the first few topics the contributor works on.  You can usually\ntell good ones after a few e-mail exchanges---their brilliance shine\nthrough, even before they become familiar with particular conventions\nof the project.\n\n> - We reduce the noise on the Git list. Most people subscribed to the \n>   list probably don't care about git-gui. So all git-gui related emails \n>   are essentially noise for them. And while the volume has been \n>   relatively low, it is not negligible.\n\nAs long as the subject is marked clearly that the discussion is\nabout git-gui, it is easy to skip such an e-mail thread if a reader\nis not interested in it.\n\nThis is related to the \"we lose the audience\" item on the other\nlist, but as a project that consumes the product of the git-core,\nthe needs of git-gui developers are of interest to git-core\ndevelopers.  If I am not mistaken, I think the recent topic about\nlogs/HEAD.lock by Dscho was to support what he's doing with git-gui,\nand what the particular git-gui topic wanted from us happened to be\nsimple enough that we didn't have to dig too deeply the consumer\nside in order to decide if the changes to git-core made sense, but\nthat may not always the case.\n\nWith a git-gui developer who is less experienced with git-core than\nDscho, it would be entirely plausible that the developer would try\nto solve an issue on git-gui side with a lot more effort than\nnecessary because the developer is not familiar with git yet, and it\nmay turn out that it can be achieved easily with much less effort on\nthe git-gui side if we made a minimum and generic change on git-core\nside.  The other way around is also possible; an inexperienced\ngit-gui developer may dream that miracles would solve an issue at\nhand, and expect that git-core side may bend over backwards to\nsupport an unreasonable one-off feature, which may never happen.\n"},{"id":"384751","messageId":"CAGr--=JQXfbJaxvYo1ue__eRHyEgKDd3mjTgxXxT=7seTU_oYA@mail.gmail.com","threadId":"52103","inReplyTo":"xmqqimoehp7u.fsf@gitster-ct.c.googlers.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Birger Skogeng Pedersen","fromEmail":"birger.sp@gmail.com","sentAt":"2019-10-24T07:37:08Z","receivedAt":"2019-10-24T07:40:26Z","isPatch":false,"sender":{"key":"birger.sp@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5260237?v=4"},"body":"Hi,\n\nI would _love_ to see git-gui development moved to GitHub (or a\nsimilar solution like Gitlab or Bitbucket). I have only submitted a\nfew patches, comments and new topics to this project. But I find the\nuse of mailing lists to be a _lot_ less efficient than using a\nrepository hosting service (like GitHub).\n\nAdvantages with GitHub\n- Tidier than emails (very much so). Threads are neatly separated in a\nsingle list, comments to threads are listed under their respective\nthread. Threads can be linked.\n- It's a lot easier to get a total overview of all issues. Especially\nuseful when you'd want to see open issues. Pratyush mentions he has a\ntext-file on his computer where he lists all the currently open\nissues. We can't see this text-file. And even if we could, we'd still\nhave to navigate the mail archives to find the discussions and read\nthe emails one page at a time.\n- It's a lot less hassle to submit patches (PRs), easier for everyone.\n\nDisadvantages\n- Git GUI contributors must have a GH account.\n- All the data (threads, discussions, patches, etc) is not backed up\nto such a large extent as it is when everyone has a copy of everything\nin their email inboxes.\n\n\nBest regards,\nBirger\n"},{"id":"384777","messageId":"20191024171616.GA40755@generichostname","threadId":"52103","inReplyTo":"CAGr--=JQXfbJaxvYo1ue__eRHyEgKDd3mjTgxXxT=7seTU_oYA@mail.gmail.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-10-24T17:16:16Z","receivedAt":"2019-10-24T17:16:22Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"On Thu, Oct 24, 2019 at 09:37:08AM +0200, Birger Skogeng Pedersen wrote:\n> - It's a lot easier to get a total overview of all issues. Especially\n> useful when you'd want to see open issues. Pratyush mentions he has a\n> text-file on his computer where he lists all the currently open\n> issues. We can't see this text-file. And even if we could, we'd still\n> have to navigate the mail archives to find the discussions and read\n> the emails one page at a time.\n\nI also had one of these text files laying around with my TODOs. Dscho\nmentioned to me a while back that it might be a good idea to move\neverything to GitGitGadget's issues. It's worked out pretty well for me\nso far and I think a couple people have even picked up some work off of\nthere. It might be worth considering moving issues to either git-gui's\nor GitGitGadget's repo.\n\nIf anything, it's no worse than the current situation since if GitHub\ngoes down for whatever reason, then Pratyush's list of issues is private\nagain. But as long as GitHub is up, then it'd be nice to have a public\nlist of issues for people to work on.\n"},{"id":"384784","messageId":"20191024190651.6ztytfm7gt2mmfnb@yadavpratyush.com","threadId":"52103","inReplyTo":"20191024171616.GA40755@generichostname","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-10-24T19:06:52Z","receivedAt":"2019-10-24T19:07:00Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 24/10/19 10:16AM, Denton Liu wrote:\n> On Thu, Oct 24, 2019 at 09:37:08AM +0200, Birger Skogeng Pedersen wrote:\n> > - It's a lot easier to get a total overview of all issues. Especially\n> > useful when you'd want to see open issues. Pratyush mentions he has a\n> > text-file on his computer where he lists all the currently open\n> > issues. We can't see this text-file. And even if we could, we'd still\n> > have to navigate the mail archives to find the discussions and read\n> > the emails one page at a time.\n> \n> I also had one of these text files laying around with my TODOs. Dscho\n> mentioned to me a while back that it might be a good idea to move\n> everything to GitGitGadget's issues. It's worked out pretty well for me\n> so far and I think a couple people have even picked up some work off of\n> there. It might be worth considering moving issues to either git-gui's\n> or GitGitGadget's repo.\n> \n> If anything, it's no worse than the current situation since if GitHub\n> goes down for whatever reason, then Pratyush's list of issues is private\n> again. But as long as GitHub is up, then it'd be nice to have a public\n> list of issues for people to work on.\n\nThat's a pretty good idea. Will do.\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"384787","messageId":"CABPp-BEHy8c3raHwf9aFXvXN0smf_WwCcNiYxQBwh7W6An60qQ@mail.gmail.com","threadId":"52103","inReplyTo":"20191023201310.thzpxyoeb3ta55dc@yadavpratyush.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-10-24T19:46:20Z","receivedAt":"2019-10-24T19:46:33Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Oct 24, 2019 at 2:45 AM Pratyush Yadav <me@yadavpratyush.com> wrote:\n>\n> Hi everyone,\n>\n> I recently had some discussions with Dscho about whether it is a better\n> idea to use GitHub for development instead of email [0]. His argument\n> was that GitHub makes it easier for newcomers to contribute, since more\n> people are familiar with GitHub compared to mailing lists. Also, it is\n> somewhat difficult to set up an email-based workflow.\n\nInteresting; I had been pondering asking the opposite question for\nfilter-repo: Even though filter-repo is tracked externally to git.git\n(since we seem to want to move to a batteries-not-included model),\nwould it be okay to ask that filter-repo contributors send patches to\nthe git mailing list (possibly specially marked somehow)?\n\nI'm debating between:\n  - Ask contributors to send filter-repo patches to the git mailing\nlist (if okay).\n  - Try out GerritHub (GitHub + Gerrit; see gerrithub.io) and maybe use it\n  - Assume there won't be many contributions (wouldn't be surprising)\nand put up with GitHub PRs\n\nGitHub is great for ease of creating new repos, learning about other\ndevelopers, finding similar projects, creation of webhooks, etc.  But\nit's *awful* for code review.  Gerrit is a lot better at code reviews\n(though still has problems); so maybe dealing with both GitHub and\nGerrit would be reasonable.  (Reviewable also exists, and is kinda\ndecent, but I can't respect anything that doesn't offer reviewability\nof commit messages.  And it makes me feel bad by making me want to\nswat butterflies.)  Email is a horrible medium for sending/receiving\nchanges, but at least it gets the overall code review model right\n(commit-messages-are-first-order-objects-that-can-be-reviewed,\nreview-individual-commits, merge-per-topic, cover-letter included,\nrange-diff for high-level comparison of different iterations,\nreversing-commit-order-display-based-on-author-timestamps-is-NOT-forgivable,\nChange-IDs-are-ugly, magic-refs-are-disgusting, etc.), something no\nGUI tool (yet) does to my knowledge.\n\n\nSo...would anyone object if I asked filter-repo contributors to send\ncontributions via email to the git mailing list?\n\nThanks,\nElijah\n"},{"id":"384795","messageId":"20191024212913.z7jkdzibp3aodpgp@yadavpratyush.com","threadId":"52103","inReplyTo":"20191024171616.GA40755@generichostname","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-10-24T21:29:14Z","receivedAt":"2019-10-24T21:29:20Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 24/10/19 10:16AM, Denton Liu wrote:\n> On Thu, Oct 24, 2019 at 09:37:08AM +0200, Birger Skogeng Pedersen wrote:\n> > - It's a lot easier to get a total overview of all issues. Especially\n> > useful when you'd want to see open issues. Pratyush mentions he has a\n> > text-file on his computer where he lists all the currently open\n> > issues. We can't see this text-file. And even if we could, we'd still\n> > have to navigate the mail archives to find the discussions and read\n> > the emails one page at a time.\n> \n> I also had one of these text files laying around with my TODOs. Dscho\n> mentioned to me a while back that it might be a good idea to move\n> everything to GitGitGadget's issues. It's worked out pretty well for me\n> so far and I think a couple people have even picked up some work off of\n> there. It might be worth considering moving issues to either git-gui's\n> or GitGitGadget's repo.\n> \n> If anything, it's no worse than the current situation since if GitHub\n> goes down for whatever reason, then Pratyush's list of issues is private\n> again. But as long as GitHub is up, then it'd be nice to have a public\n> list of issues for people to work on.\n\nUpdate: the list can be now be found at [0].\n\n[0] https://github.com/prati0100/git-gui/issues\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"384843","messageId":"CAGr--=KXUedDtX3Dtx8jRm1Ge6sgk0v+CPq36tbOAnhnVDYQTw@mail.gmail.com","threadId":"52103","inReplyTo":"20191024212913.z7jkdzibp3aodpgp@yadavpratyush.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Birger Skogeng Pedersen","fromEmail":"birger.sp@gmail.com","sentAt":"2019-10-25T05:33:21Z","receivedAt":"2019-10-25T05:36:42Z","isPatch":false,"sender":{"key":"birger.sp@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5260237?v=4"},"body":"Hi Pratyush,\n\nOn Thu, Oct 24, 2019 at 11:29 PM Pratyush Yadav <me@yadavpratyush.com> wrote:\n> Update: the list can be now be found at [0].\n>\n> [0] https://github.com/prati0100/git-gui/issues\n\nIs that the full list? If so I'll add my issue [1] about automatically\nselecting a staged file (avoid an empty diff) when focusing the commit\nmessage widget.\n\n[1] https://public-inbox.org/git/CAGr--=KMJmYtVaATFkOPcboAdkLvpZFbWAo4QAE0-uC6RL4Lqg@mail.gmail.com/\n\nBirger\n"},{"id":"384879","messageId":"20191025174719.zbxkeyt4645z5xlm@yadavpratyush.com","threadId":"52103","inReplyTo":"CAGr--=KXUedDtX3Dtx8jRm1Ge6sgk0v+CPq36tbOAnhnVDYQTw@mail.gmail.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-10-25T17:47:19Z","receivedAt":"2019-10-25T17:47:25Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 25/10/19 07:33AM, Birger Skogeng Pedersen wrote:\n> Hi Pratyush,\n> \n> On Thu, Oct 24, 2019 at 11:29 PM Pratyush Yadav <me@yadavpratyush.com> wrote:\n> > Update: the list can be now be found at [0].\n> >\n> > [0] https://github.com/prati0100/git-gui/issues\n> \n> Is that the full list? If so I'll add my issue [1] about automatically\n> selecting a staged file (avoid an empty diff) when focusing the commit\n> message widget.\n\nYes, it is the full list in the sense that it has all the items in my \nTODO list. But, it is not an \"official\" bug tracker. At least not until \nwe switch to GitHub, if ever.\n\nSo, if you feel like it, go ahead and add your issue there. No problems. \nBut you don't _have_ to.\n \n> [1] https://public-inbox.org/git/CAGr--=KMJmYtVaATFkOPcboAdkLvpZFbWAo4QAE0-uC6RL4Lqg@mail.gmail.com/\n> \n> Birger\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"384882","messageId":"20191025183605.zk2g43z2townbigj@yadavpratyush.com","threadId":"52103","inReplyTo":"CABPp-BEHy8c3raHwf9aFXvXN0smf_WwCcNiYxQBwh7W6An60qQ@mail.gmail.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-10-25T18:36:05Z","receivedAt":"2019-10-25T18:36:13Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 24/10/19 12:46PM, Elijah Newren wrote:\n> On Thu, Oct 24, 2019 at 2:45 AM Pratyush Yadav <me@yadavpratyush.com> wrote:\n> >\n> > Hi everyone,\n> >\n> > I recently had some discussions with Dscho about whether it is a better\n> > idea to use GitHub for development instead of email [0]. His argument\n> > was that GitHub makes it easier for newcomers to contribute, since more\n> > people are familiar with GitHub compared to mailing lists. Also, it is\n> > somewhat difficult to set up an email-based workflow.\n> \n> Interesting; I had been pondering asking the opposite question for\n> filter-repo: Even though filter-repo is tracked externally to git.git\n> (since we seem to want to move to a batteries-not-included model),\n> would it be okay to ask that filter-repo contributors send patches to\n> the git mailing list (possibly specially marked somehow)?\n\nMarking them some way (like we do with git-gui) would probably be a good \nidea since it allows people to just skip over those threads if they're \nnot interested. It also allows using email filters on those topics.\n \n> I'm debating between:\n>   - Ask contributors to send filter-repo patches to the git mailing\n> list (if okay).\n>   - Try out GerritHub (GitHub + Gerrit; see gerrithub.io) and maybe use it\n>   - Assume there won't be many contributions (wouldn't be surprising)\n> and put up with GitHub PRs\n> \n> GitHub is great for ease of creating new repos, learning about other\n> developers, finding similar projects, creation of webhooks, etc.  But\n> it's *awful* for code review.  Gerrit is a lot better at code reviews\n> (though still has problems); so maybe dealing with both GitHub and\n> Gerrit would be reasonable.  (Reviewable also exists, and is kinda\n> decent, but I can't respect anything that doesn't offer reviewability\n> of commit messages.  And it makes me feel bad by making me want to\n> swat butterflies.)  Email is a horrible medium for sending/receiving\n> changes, but at least it gets the overall code review model right\n> (commit-messages-are-first-order-objects-that-can-be-reviewed,\n> review-individual-commits, merge-per-topic, cover-letter included,\n> range-diff for high-level comparison of different iterations,\n> reversing-commit-order-display-based-on-author-timestamps-is-NOT-forgivable,\n> Change-IDs-are-ugly, magic-refs-are-disgusting, etc.), something no\n> GUI tool (yet) does to my knowledge.\n\nThanks for your perspective. I have never really used GitHub for \nanything more than one off contributions, and so never really ended up \nusing their review and merge tools too much. In fact, most of the open \nsource projects I have been interested in used mailing lists, which is \nwhy I questioned myself if I'm biased towards such a workflow.\n \n> So...would anyone object if I asked filter-repo contributors to send\n> contributions via email to the git mailing list?\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"384916","messageId":"86k18rbbyz.fsf@gmail.com","threadId":"52103","inReplyTo":"CABPp-BEHy8c3raHwf9aFXvXN0smf_WwCcNiYxQBwh7W6An60qQ@mail.gmail.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2019-10-26T18:25:40Z","receivedAt":"2019-10-26T18:25:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n> On Thu, Oct 24, 2019 at 2:45 AM Pratyush Yadav <me@yadavpratyush.com> wrote:\n>>\n>> I recently had some discussions with Dscho about whether it is a better\n>> idea to use GitHub for development instead of email [0]. His argument\n>> was that GitHub makes it easier for newcomers to contribute, since more\n>> people are familiar with GitHub compared to mailing lists. Also, it is\n>> somewhat difficult to set up an email-based workflow.\n[...]\n> GitHub is great for ease of creating new repos, learning about other\n> developers, finding similar projects, creation of webhooks, etc.  But\n> it's *awful* for code review.  Gerrit is a lot better at code reviews\n> (though still has problems); so maybe dealing with both GitHub and\n> Gerrit would be reasonable.\n[...]\n> Email is a horrible medium for sending/receiving\n> changes, but at least it gets the overall code review model right\n> (commit-messages-are-first-order-objects-that-can-be-reviewed,\n> review-individual-commits, merge-per-topic, cover-letter included,\n> range-diff for high-level comparison of different iterations,\n> reversing-commit-order-display-based-on-author-timestamps-is-NOT-forgivable,\n> Change-IDs-are-ugly, magic-refs-are-disgusting, etc.), something no\n> GUI tool (yet) does to my knowledge.\n\nI agree with that.  You need then to decide whether it is better to have\nit easier for beginners to contribute, or is it better to have it easier\nto review code.  What are the pain points?\n\n\nAnother source worth looking into is \"Patches carved into stone tablets,\nwhy the Linux kernel developers rely on plain text email instead of\nusing “modern” development tools.\" presentation by Greg KH from\n2016[1][2].  But remember that git-gui is not Linux kernel; what works\nfor one might not work for the other.\n\nIt is unfortunate that we have no tools described in \"Patches carved\ninto developer sigchains\"[3] wishfull blog post by Konstantin Ryabitsev...\n\n[1]: https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/\n[2]: https://www.slideshare.net/ennael/kernel-recipes-2016-patches-carved-into-stone-tablets\n[3]: https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains\n\nRegards,\n--\nJakub Narębski\n"},{"id":"384971","messageId":"20191028101347.pofpm6m3hbxjhwlg@pure.paranoia.local","threadId":"52103","inReplyTo":"86k18rbbyz.fsf@gmail.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2019-10-28T10:13:47Z","receivedAt":"2019-10-28T10:13:53Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Sat, Oct 26, 2019 at 08:25:40PM +0200, Jakub Narebski wrote:\n> It is unfortunate that we have no tools described in \"Patches carved\n> into developer sigchains\"[3] wishfull blog post by Konstantin Ryabitsev...\n\nWe are working to get us there. It's going to be a long process and we\nare choosing the evolutionary approach as opposed to staging a\nrevolution. :)\n\n-K\n"},{"id":"385137","messageId":"CABPp-BG2SkH0GrRYpHLfp2Wey91ThwQoTgf9UmPa9f5Szn+v3Q@mail.gmail.com","threadId":"52103","inReplyTo":"86k18rbbyz.fsf@gmail.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-10-30T06:21:15Z","receivedAt":"2019-10-30T06:21:30Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sat, Oct 26, 2019 at 11:25 AM Jakub Narebski <jnareb@gmail.com> wrote:\n>\n> Elijah Newren <newren@gmail.com> writes:\n> > On Thu, Oct 24, 2019 at 2:45 AM Pratyush Yadav <me@yadavpratyush.com> wrote:\n> >>\n> >> I recently had some discussions with Dscho about whether it is a better\n> >> idea to use GitHub for development instead of email [0]. His argument\n> >> was that GitHub makes it easier for newcomers to contribute, since more\n> >> people are familiar with GitHub compared to mailing lists. Also, it is\n> >> somewhat difficult to set up an email-based workflow.\n> [...]\n> > GitHub is great for ease of creating new repos, learning about other\n> > developers, finding similar projects, creation of webhooks, etc.  But\n> > it's *awful* for code review.  Gerrit is a lot better at code reviews\n> > (though still has problems); so maybe dealing with both GitHub and\n> > Gerrit would be reasonable.\n> [...]\n> > Email is a horrible medium for sending/receiving\n> > changes, but at least it gets the overall code review model right\n> > (commit-messages-are-first-order-objects-that-can-be-reviewed,\n> > review-individual-commits, merge-per-topic, cover-letter included,\n> > range-diff for high-level comparison of different iterations,\n> > reversing-commit-order-display-based-on-author-timestamps-is-NOT-forgivable,\n> > Change-IDs-are-ugly, magic-refs-are-disgusting, etc.), something no\n> > GUI tool (yet) does to my knowledge.\n>\n> I agree with that.  You need then to decide whether it is better to have\n> it easier for beginners to contribute, or is it better to have it easier\n> to review code.  What are the pain points?\n\nI don't think that's the right comparison to make.  The problems with\nGitHub code review aren't solely ease-of-use issues, they are more a\nquality-of-code issues.\n\nProjects which switch to GitHub tend to have overall commit quality go\ndown IMO, because the system (a) makes it nearly impossible to review\ncommit messages, so people eventually degrade to writing really bad\nones, (b) makes it nearly impossible to review a rebased set of\nchanges except redoing the entire review from square one, so people\ndon't rebase, (c) punishes both users and reviewers who want to work\nwith a rebased patch series by displaying the series out of order --\neven for a completely linear history (it resorts based on author\ntimestamp, not even committer timestamp), and (d) punishes\nreviewers/users when they attempt to review individual commits by\nmaking it harder to see and follow these comments (though it has\ngotten much better on this front).  There are combination effects too.\nPeople to write really bad commit messages for all the additional\n\"fixups\" they have.  People notice that commits don't bisect nicely,\nand instead of understanding that the broken code review system they\nwrote was the problem, they instead offer a new \"squash merge\" option,\nthus destroying all the carefully separated commits that help people\nunderstand the individual steps toward the new feature and making it\nimpossible for anyone in the future to review it incrementally.  You\nmay say it's a workflow choice for some people to just squash all\ntheir stuff together at their option, which would be fine, but the\nproblem is most developers don't take the time to think, and someone\nin charge of the project notices that they keep getting un-bisectable\nmeaningless commits unless they force *everyone* in the project to use\nsquash merging.  Now they are punishing me for creating clean separate\ncommits and forcing them all to be squashed -- all as an ugly\nworkaround to the basic tool being *broken*.  You can work around this\nby making a long sequence of PRs, one per what you intend to be a\ncommit, and try to track the hierarchy -- something that GitHub\ncertainly doesn't make easy.  And then each PR becomes a trivial small\nchange, and you are back to merging individual commits, and writing\nyour own tools to manage a hierarchy of PRs...and reviewers hate you\nif you do that because it's extremely onerous on them.\n\nGitHub PRs aren't just hard to use, they literally degrade the quality\nof the code for people who have to use it.  I've seen it happen with\nmany projects.\n\n(At $DAYJOB, they have hundreds of repos and have at times used SVN\nthen gitolite then gerrit then (Atlassian) stash then github (with\nother review tools like sourcegraph and reviewable tried and a few\nothers read up on), with most of those existing simultaneously --\nthough we eventually pruned it down to just Gerrit and GitHub, with\nsome projects in one and some in the other system.  I've seen\nmigrations between various combinations of these tools (though SVN and\ngitolite were nearly phased out by the time I joined), and seen\nresults of how the tools caused differences in behavior.  And yes, I\nknow that GitHub's popularity means many have copied GitHub's PR\nmodel, from sourcegraph who were basically identical, to Stash which\nis similar but handled rebases better, and I think GitLab looks\nsimilar though I haven't used it that much (yet).  Reviewable handled\nrebases a lot better, but still used the utterly broken model of not\nallowing commit messages to be reviewed -- and glitterbombed the\ninterface with butterflies.)\n\n> Another source worth looking into is \"Patches carved into stone tablets,\n> why the Linux kernel developers rely on plain text email instead of\n> using “modern” development tools.\" presentation by Greg KH from\n> 2016[1][2].  But remember that git-gui is not Linux kernel; what works\n> for one might not work for the other.\n>\n> It is unfortunate that we have no tools described in \"Patches carved\n> into developer sigchains\"[3] wishfull blog post by Konstantin Ryabitsev...\n\nInteresting links; thanks for providing them.  And yes, I agree that\ngit-gui won't necessarily have the same tradeoffs as the Linux kernel.\nBut I do tend to be noisy here hoping I can spark someone with a\nmodicum of talent for front-end development (I have neither the talent\nnor the inclination for web development) to write a sane webby code\nreview system.  Much of GitHub is awesome.  And it has some apparently\nreally nice thing for web devs, which seems to be part of why so many\npeople use it.  It's just so terribly awful at code reviews.  But\nsystems like Reviewable and GerritHub build on top of GitHub, so maybe\nthere is hope someone can build just the review part and make it\nawesome.\n\n> [1]: https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/\n> [2]: https://www.slideshare.net/ennael/kernel-recipes-2016-patches-carved-into-stone-tablets\n> [3]: https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains\n>\n> Regards,\n> --\n> Jakub Narębski\n"},{"id":"386636","messageId":"CAGr--=LKBq17XSLpe=uJbEPSfCp5Fpi_uw4d87DgJ8-S4Md0kQ@mail.gmail.com","threadId":"52103","inReplyTo":"CABPp-BG2SkH0GrRYpHLfp2Wey91ThwQoTgf9UmPa9f5Szn+v3Q@mail.gmail.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Birger Skogeng Pedersen","fromEmail":"birger.sp@gmail.com","sentAt":"2019-11-20T12:19:22Z","receivedAt":"2019-11-20T12:20:11Z","isPatch":false,"sender":{"key":"birger.sp@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5260237?v=4"},"body":"Hei Elijah,\n\nOn Wed, Oct 30, 2019 at 7:21 AM Elijah Newren <newren@gmail.com> wrote:\n> Projects which switch to GitHub tend to have overall commit quality go\n> down IMO, because the system (a) makes it nearly impossible to review\n> commit messages, so people eventually degrade to writing really bad\n> ones,\nWhat do you mean here, exactly? In what way is it \"nearly impossible\"\nto review commit messages in GH?\n\nbr\nBirger\n"},{"id":"386647","messageId":"CABPp-BEcpasV4vBTm0uxQ4Vzm88MQAX-ArDG4e9QU8tEoNsZWw@mail.gmail.com","threadId":"52103","inReplyTo":"CAGr--=LKBq17XSLpe=uJbEPSfCp5Fpi_uw4d87DgJ8-S4Md0kQ@mail.gmail.com","subject":"Re: RFC: Moving git-gui development to GitHub","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-11-20T17:13:04Z","receivedAt":"2019-11-20T17:13:20Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Nov 20, 2019 at 4:20 AM Birger Skogeng Pedersen\n<birger.sp@gmail.com> wrote:\n>\n> Hei Elijah,\n>\n> On Wed, Oct 30, 2019 at 7:21 AM Elijah Newren <newren@gmail.com> wrote:\n> > Projects which switch to GitHub tend to have overall commit quality go\n> > down IMO, because the system (a) makes it nearly impossible to review\n> > commit messages, so people eventually degrade to writing really bad\n> > ones,\n> What do you mean here, exactly? In what way is it \"nearly impossible\"\n> to review commit messages in GH?\n\nMy lengthy rant wasn't good enough for you?  ;-)  Well, I'll try even\nharder to bore everyone to death, then and extend my rant a bit...\n\n\nReviewing is the process of providing feedback on proposed changes.\nCode review tools and mechanisms typically provide ways to (a) see\nproposed changes in isolation and (b) comment on individual lines and\npreserve context (with the goal of later merging a group of commits\nthat implement something useful).\n\ngit-format-patch and git-send-email combined with usage of email\nclients that know how to quote previous emails and let you respond\ninline are a natural way of achieving both (a) and (b).\n\nGUI tools can, of course, also achieve something similar by showing\nproposed changes and allowing commenting on individual lines in\ncontext.  GitHub fails pretty hard on both counts, particularly for\ncommit messages.  It guides people to an overall diff rather than to\nthe diffs inside individual commits and completely omits all commit\nmessages when you do so.  It does provide a way to access individual\ncommits and their diffs, though it makes it somewhat unnatural.  (It\nat least isn't as awful as it used to be in years past, when any\ncomments on individual commits were completely lost and separated from\nthe PR.)  And even if you do \"go against the grain\" to comment on\nindividual commits, there is no provided mechanism for commenting on\nthe commit message itself.  Instead it has to be given as a general\ncomment on the overall set of changes, which then loses the context of\nwhat you are commenting on unless you re-include and quote it\nyourself.  That usually doesn't happen, so when you comment on four\ncommit messages in a review, you have four separate global comments\nand someone attempting to respond to them doesn't get to see the\ncommit messages next to them, resulting in confusion.  Even if you do\nre-include and quote the commit message bits you are commenting on,\nthe resulting comment isn't in any way tied to the commit in question\nin the UI.\n\nSo people who use GitHub for code review just don't bother.   They\nwrite non-isolated commits and far from rarely use awful commit\nmessages.  Then they merge this abomination of history, or possibly\neven worse, they squash merge it all to make it impossible for any\nfuture readers to be able to dissect.\n\nYeah, yeah, small features so that the review is smaller and easier.\nThat is important, yes, but it still conflates two things and thus\nruins reviews.  Each PR should implement something useful.  Commits\nshould be designed both for current and future reviewers to see a\nclear path towards how that useful thing was implemented.  Sometimes\none commit is enough, but conflating the two necessarily either means\nsometimes creating one-commit PRs that don't actually implement\nanything useful, or a cognitive overload for code reviewers.  GitHub\nsimultaneously encourages bad behavior (bad commit messages since they\nare designed to not be reviewable, non-isolated commits, fixup commits\nthat are never properly squashed, etc.) and penalizes good behavior\n(folks who try to clean up their sequence of commits are met with\nproblems ranging from GitHub screwing up the topological ordering of a\nlinear commit history, to poor ability to see incremental changes\nwhenever rebasing happens, to reckless squash merging of all their\ncareful work into a single commit as something close to an act of war\nagainst any future readers who want to dig into why certain changes\nwere made).  Yes, GitHub has gotten much better at code reviews; it's\nmerely abysmally awful these days as opposed to a complete joke as it\nwas in years past.  But it's still so bad that I have seen people try\nto solve this by having a sequence of PRs per (small) feature they\nwant to implement, even though GitHub provides no way to denote\ndependencies or ordering between PRs.\n\nYou may think I've gone off on a bunch of tangents, but fundamentally\nI believe that almost all of these other problems predominantly arise\nas secondary and tertiary effects of not understanding that commit\nmessages should be a first class citizen of code review.\n\nSure, you can claim all you want that it is entirely possible to\nreview commit messages within the GitHub UI and it's just extremely\ninconvenient, yadda, yadda, but the truth of the matter is that people\neverywhere struggle to even do code reviews at all, and when they do\nthey all too often turn into rubberstamp exercises or don't delve\ndeeply enough.  In that context, I believe my \"nearly impossible\"\nwording is entirely warranted.  Using a tool that simultaneously\nencourages bad behavior and penalizes good behavior will not so\nsurprisingly yield bad behavior.  GitHub PRs are such a tool, IMO.\n\n(To be fair, I'll note that GitHub has awesome code browsing, really\neasy setup and administration of new repositories and organizations,\nsimple and reasonable and thus pretty nice code search, etc., etc.\nI'm not saying GitHub is a bad tool, I actually think most of it is a\nvery excellent tool; I am just claiming that the PR section of it is\nvery bad.)\n\n\nElijah\n"},{"id":"422335","messageId":"20210419203327.GV2947267@szeder.dev","threadId":"52103","inReplyTo":"CABPp-BEcpasV4vBTm0uxQ4Vzm88MQAX-ArDG4e9QU8tEoNsZWw@mail.gmail.com","subject":"Pain points in PRs [was: Re: RFC: Moving git-gui development to GitHub]","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2021-04-19T20:33:27Z","receivedAt":"2021-04-19T20:35:17Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Wed, Nov 20, 2019 at 09:13:04AM -0800, Elijah Newren wrote:\n> > On Wed, Oct 30, 2019 at 7:21 AM Elijah Newren <newren@gmail.com> wrote:\n> > > Projects which switch to GitHub tend to have overall commit quality go\n> > > down IMO, because the system (a) makes it nearly impossible to review\n> > > commit messages, so people eventually degrade to writing really bad\n> > > ones,\n> > What do you mean here, exactly? In what way is it \"nearly impossible\"\n> > to review commit messages in GH?\n> \n> My lengthy rant wasn't good enough for you?  ;-)  Well, I'll try even\n> harder to bore everyone to death, then and extend my rant a bit...\n\nThank you very much for taking the time and effort to write it up.\n\nIt summarized some of my main gripes with PR-based collaboration on\nGitHub with such clarity that I would never been able to achive.\n\n(The recent \"Pain points in Git's patch flow\" thread reminded me that\nI saved this message and even marked it as important ages ago... but\nhaven't gotten around to read it until now.\n\n  https://public-inbox.org/git/YHaIBvl6Mf7ztJB3@google.com/T/\n)\n\n> Reviewing is the process of providing feedback on proposed changes.\n> Code review tools and mechanisms typically provide ways to (a) see\n> proposed changes in isolation and (b) comment on individual lines and\n> preserve context (with the goal of later merging a group of commits\n> that implement something useful).\n> \n> git-format-patch and git-send-email combined with usage of email\n> clients that know how to quote previous emails and let you respond\n> inline are a natural way of achieving both (a) and (b).\n> \n> GUI tools can, of course, also achieve something similar by showing\n> proposed changes and allowing commenting on individual lines in\n> context.  GitHub fails pretty hard on both counts, particularly for\n> commit messages.  It guides people to an overall diff rather than to\n> the diffs inside individual commits and completely omits all commit\n> messages when you do so.  It does provide a way to access individual\n> commits and their diffs, though it makes it somewhat unnatural.  (It\n> at least isn't as awful as it used to be in years past, when any\n> comments on individual commits were completely lost and separated from\n> the PR.)  And even if you do \"go against the grain\" to comment on\n> individual commits, there is no provided mechanism for commenting on\n> the commit message itself.  Instead it has to be given as a general\n> comment on the overall set of changes, which then loses the context of\n> what you are commenting on unless you re-include and quote it\n> yourself.  That usually doesn't happen, so when you comment on four\n> commit messages in a review, you have four separate global comments\n> and someone attempting to respond to them doesn't get to see the\n> commit messages next to them, resulting in confusion.  Even if you do\n> re-include and quote the commit message bits you are commenting on,\n> the resulting comment isn't in any way tied to the commit in question\n> in the UI.\n> \n> So people who use GitHub for code review just don't bother.   They\n> write non-isolated commits and far from rarely use awful commit\n> messages.  Then they merge this abomination of history, or possibly\n> even worse, they squash merge it all to make it impossible for any\n> future readers to be able to dissect.\n> \n> Yeah, yeah, small features so that the review is smaller and easier.\n> That is important, yes, but it still conflates two things and thus\n> ruins reviews.  Each PR should implement something useful.  Commits\n> should be designed both for current and future reviewers to see a\n> clear path towards how that useful thing was implemented.  Sometimes\n> one commit is enough, but conflating the two necessarily either means\n> sometimes creating one-commit PRs that don't actually implement\n> anything useful, or a cognitive overload for code reviewers.  GitHub\n> simultaneously encourages bad behavior (bad commit messages since they\n> are designed to not be reviewable, non-isolated commits, fixup commits\n> that are never properly squashed, etc.) and penalizes good behavior\n> (folks who try to clean up their sequence of commits are met with\n> problems ranging from GitHub screwing up the topological ordering of a\n> linear commit history, to poor ability to see incremental changes\n> whenever rebasing happens, to reckless squash merging of all their\n> careful work into a single commit as something close to an act of war\n> against any future readers who want to dig into why certain changes\n> were made).  Yes, GitHub has gotten much better at code reviews; it's\n> merely abysmally awful these days as opposed to a complete joke as it\n> was in years past.  But it's still so bad that I have seen people try\n> to solve this by having a sequence of PRs per (small) feature they\n> want to implement, even though GitHub provides no way to denote\n> dependencies or ordering between PRs.\n> \n> You may think I've gone off on a bunch of tangents, but fundamentally\n> I believe that almost all of these other problems predominantly arise\n> as secondary and tertiary effects of not understanding that commit\n> messages should be a first class citizen of code review.\n> \n> Sure, you can claim all you want that it is entirely possible to\n> review commit messages within the GitHub UI and it's just extremely\n> inconvenient, yadda, yadda, but the truth of the matter is that people\n> everywhere struggle to even do code reviews at all, and when they do\n> they all too often turn into rubberstamp exercises or don't delve\n> deeply enough.  In that context, I believe my \"nearly impossible\"\n> wording is entirely warranted.  Using a tool that simultaneously\n> encourages bad behavior and penalizes good behavior will not so\n> surprisingly yield bad behavior.  GitHub PRs are such a tool, IMO.\n> \n> (To be fair, I'll note that GitHub has awesome code browsing, really\n> easy setup and administration of new repositories and organizations,\n> simple and reasonable and thus pretty nice code search, etc., etc.\n> I'm not saying GitHub is a bad tool, I actually think most of it is a\n> very excellent tool; I am just claiming that the PR section of it is\n> very bad.)\n> \n> \n> Elijah\n"},{"id":"422344","messageId":"xmqqsg3m7xin.fsf@gitster.g","threadId":"52103","inReplyTo":"20210419203327.GV2947267@szeder.dev","subject":"Re: Pain points in PRs [was: Re: RFC: Moving git-gui development to GitHub]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-19T21:52:16Z","receivedAt":"2021-04-19T21:52:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor <szeder.dev@gmail.com> writes:\n\n> On Wed, Nov 20, 2019 at 09:13:04AM -0800, Elijah Newren wrote:\n>> > On Wed, Oct 30, 2019 at 7:21 AM Elijah Newren <newren@gmail.com> wrote:\n>> > > Projects which switch to GitHub tend to have overall commit quality go\n>> > > down IMO, because the system (a) makes it nearly impossible to review\n>> > > commit messages, so people eventually degrade to writing really bad\n>> > > ones,\n>> > What do you mean here, exactly? In what way is it \"nearly impossible\"\n>> > to review commit messages in GH?\n>> \n>> My lengthy rant wasn't good enough for you?  ;-)  Well, I'll try even\n>> harder to bore everyone to death, then and extend my rant a bit...\n>\n> Thank you very much for taking the time and effort to write it up.\n>\n> It summarized some of my main gripes with PR-based collaboration on\n> GitHub with such clarity that I would never been able to achive.\n>\n> (The recent \"Pain points in Git's patch flow\" thread reminded me that\n> I saved this message and even marked it as important ages ago... but\n> haven't gotten around to read it until now.\n>\n>   https://public-inbox.org/git/YHaIBvl6Mf7ztJB3@google.com/T/\n> )\n\nInteresting.\n\nI recently had a similar experience with Gerrit, where a patch I\nhave seen quite a few times on Gerrit at $WORK had an embarrassing\nsyntactic issues I did not discover until it hit the public mailing\nlist.  It may be different from reviewer to reviewer, but at least\nto me, e-mailed workflow forces me to apply the patch to my tree\nbefore I can say anything non-trivially intelligent about it and\nonce applied to the tree, it actually let's me play with the code\n(like, say, asking the compiler to give its opinion on it).\n\nThe experience I had with Gerrit at $WORK gave me side-to-side diff\nwith context with arbitrary on-demand width, even with per-word\ndifferences highlighted, and it may be wonderful that I can get all\nof these _without_ having to apply the patch myself, but what it\ngave me stopped there.  There are a lot more things that need to\nhappen beyond looking at what changed in the context of the files\nduring a review, from grepping in the tree for functions and\nvariables used in the patch to see their uses in other parts of the\nsystem that the patch does not touch, to make various trial merges\nto different topics that are in flight, and Gerrit didn't help me an\niota, but still gave me a (false) impression that I _did_ review the\npatch fully, when I only have scraped its surface, and the worst\npart of the story was that the UI feld so nice that I didn't even\nrealize that I was doing a lot more shoddy job in reviewing than\nwhat I usually do to e-mailed patches.\n\n\n>> Reviewing is the process of providing feedback on proposed changes.\n>> Code review tools and mechanisms typically provide ways to (a) see\n>> proposed changes in isolation and (b) comment on individual lines and\n>> preserve context (with the goal of later merging a group of commits\n>> that implement something useful).\n>> \n>> git-format-patch and git-send-email combined with usage of email\n>> clients that know how to quote previous emails and let you respond\n>> inline are a natural way of achieving both (a) and (b).\n>> \n>> GUI tools can, of course, also achieve something similar by showing\n>> proposed changes and allowing commenting on individual lines in\n>> context.  GitHub fails pretty hard on both counts, particularly for\n>> commit messages.  It guides people to an overall diff rather than to\n>> the diffs inside individual commits and completely omits all commit\n>> messages when you do so.  It does provide a way to access individual\n>> commits and their diffs, though it makes it somewhat unnatural.  (It\n>> at least isn't as awful as it used to be in years past, when any\n>> comments on individual commits were completely lost and separated from\n>> the PR.)  And even if you do \"go against the grain\" to comment on\n>> individual commits, there is no provided mechanism for commenting on\n>> the commit message itself.  Instead it has to be given as a general\n>> comment on the overall set of changes, which then loses the context of\n>> what you are commenting on unless you re-include and quote it\n>> yourself.  That usually doesn't happen, so when you comment on four\n>> commit messages in a review, you have four separate global comments\n>> and someone attempting to respond to them doesn't get to see the\n>> commit messages next to them, resulting in confusion.  Even if you do\n>> re-include and quote the commit message bits you are commenting on,\n>> the resulting comment isn't in any way tied to the commit in question\n>> in the UI.\n>> \n>> So people who use GitHub for code review just don't bother.   They\n>> write non-isolated commits and far from rarely use awful commit\n>> messages.  Then they merge this abomination of history, or possibly\n>> even worse, they squash merge it all to make it impossible for any\n>> future readers to be able to dissect.\n>> \n>> Yeah, yeah, small features so that the review is smaller and easier.\n>> That is important, yes, but it still conflates two things and thus\n>> ruins reviews.  Each PR should implement something useful.  Commits\n>> should be designed both for current and future reviewers to see a\n>> clear path towards how that useful thing was implemented.  Sometimes\n>> one commit is enough, but conflating the two necessarily either means\n>> sometimes creating one-commit PRs that don't actually implement\n>> anything useful, or a cognitive overload for code reviewers.  GitHub\n>> simultaneously encourages bad behavior (bad commit messages since they\n>> are designed to not be reviewable, non-isolated commits, fixup commits\n>> that are never properly squashed, etc.) and penalizes good behavior\n>> (folks who try to clean up their sequence of commits are met with\n>> problems ranging from GitHub screwing up the topological ordering of a\n>> linear commit history, to poor ability to see incremental changes\n>> whenever rebasing happens, to reckless squash merging of all their\n>> careful work into a single commit as something close to an act of war\n>> against any future readers who want to dig into why certain changes\n>> were made).  Yes, GitHub has gotten much better at code reviews; it's\n>> merely abysmally awful these days as opposed to a complete joke as it\n>> was in years past.  But it's still so bad that I have seen people try\n>> to solve this by having a sequence of PRs per (small) feature they\n>> want to implement, even though GitHub provides no way to denote\n>> dependencies or ordering between PRs.\n>> \n>> You may think I've gone off on a bunch of tangents, but fundamentally\n>> I believe that almost all of these other problems predominantly arise\n>> as secondary and tertiary effects of not understanding that commit\n>> messages should be a first class citizen of code review.\n>> \n>> Sure, you can claim all you want that it is entirely possible to\n>> review commit messages within the GitHub UI and it's just extremely\n>> inconvenient, yadda, yadda, but the truth of the matter is that people\n>> everywhere struggle to even do code reviews at all, and when they do\n>> they all too often turn into rubberstamp exercises or don't delve\n>> deeply enough.  In that context, I believe my \"nearly impossible\"\n>> wording is entirely warranted.  Using a tool that simultaneously\n>> encourages bad behavior and penalizes good behavior will not so\n>> surprisingly yield bad behavior.  GitHub PRs are such a tool, IMO.\n>> \n>> (To be fair, I'll note that GitHub has awesome code browsing, really\n>> easy setup and administration of new repositories and organizations,\n>> simple and reasonable and thus pretty nice code search, etc., etc.\n>> I'm not saying GitHub is a bad tool, I actually think most of it is a\n>> very excellent tool; I am just claiming that the PR section of it is\n>> very bad.)\n>> \n>> \n>> Elijah\n"},{"id":"422371","messageId":"YH6Hj2/fGimrLuZ+@C02YX140LVDN.corpad.adbkng.com","threadId":"52103","inReplyTo":"xmqqsg3m7xin.fsf@gitster.g","subject":"Re: Pain points in PRs [was: Re: RFC: Moving git-gui development to GitHub]","fromName":"Son Luong Ngoc","fromEmail":"sluongng@gmail.com","sentAt":"2021-04-20T07:49:35Z","receivedAt":"2021-04-20T07:49:44Z","isPatch":false,"sender":{"key":"sluongng@gmail.com","avatar":"https://avatars.githubusercontent.com/u/26684313?v=4"},"body":"Hi Junio,\n\nOn Mon, Apr 19, 2021 at 02:52:16PM -0700, Junio C Hamano wrote:\n> \n> Interesting.\n> \n> I recently had a similar experience with Gerrit, where a patch I\n> have seen quite a few times on Gerrit at $WORK had an embarrassing\n> syntactic issues I did not discover until it hit the public mailing\n> list.  It may be different from reviewer to reviewer, but at least\n> to me, e-mailed workflow forces me to apply the patch to my tree\n> before I can say anything non-trivially intelligent about it and\n> once applied to the tree, it actually let's me play with the code\n> (like, say, asking the compiler to give its opinion on it).\n> \n\nI think this is very much the point of having a good CI pipeline:\n  - Apply patches into tree\n  - Compile\n  - Run relevant tests\n\nI'm not sure about Github PR, but Gitlab's MR workflow also provide a\nmerge queue implementation(Merge Train) coupled with CI to ensure the\nmerge result is accurately verified against tests.\n\nWhat might be missing from (most) CI services is a bisect pipeline that\nhelp us identify culprit commit that broke the tests, but that could be\nengineered.\n\n> The experience I had with Gerrit at $WORK gave me side-to-side diff\n> with context with arbitrary on-demand width, even with per-word\n> differences highlighted, and it may be wonderful that I can get all\n> of these _without_ having to apply the patch myself, but what it\n> gave me stopped there.  There are a lot more things that need to\n> happen beyond looking at what changed in the context of the files\n> during a review, from grepping in the tree for functions and\n> variables used in the patch to see their uses in other parts of the\n> system that the patch does not touch, to make various trial merges\n> to different topics that are in flight, and Gerrit didn't help me an\n> iota, but still gave me a (false) impression that I _did_ review the\n> patch fully, when I only have scraped its surface, and the worst\n> part of the story was that the UI feld so nice that I didn't even\n> realize that I was doing a lot more shoddy job in reviewing than\n> what I usually do to e-mailed patches.\n> \n\nYes, having context beyond the diff is very important for Code Review.\nThis is why I strongly recommend SourceGraph usages to folks I know.\n\n  > https://sourcegraph.com/github.com/git/git/-/blob/builtin/repack.c#L61:13\n  > https://sourcegraph.com/github.com/git/git/-/commit/9218c6a40c37023a1f434222d501218cf8157857#diff-01ec5e99d04fb7ba9753f219ab638469R64\n\n(I have no affiliation with SourceGraph, just really enjoy their product)\n\nA mordern codesearch service like sourcegraph could help decorate diff\nwith relevant code intelligent like finding references, definitions and\nassist with the Code Review process.\n\nAfaik, sourcegraph has been building more integrations with Github and\nGitlab, not too sure about Gerrit (but Im sure it's not far reach given\ntheir GraphQL API).\n\nSo I guess mordern toolings are available for these usecases, but\nfragmented and subjective to personal workflow.\n\nRegards,\nSon Luong.\n"},{"id":"422469","messageId":"xmqqa6ps6794.fsf@gitster.g","threadId":"52103","inReplyTo":"YH6Hj2/fGimrLuZ+@C02YX140LVDN.corpad.adbkng.com","subject":"Re: Pain points in PRs [was: Re: RFC: Moving git-gui development to GitHub]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-20T20:17:11Z","receivedAt":"2021-04-20T20:17:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Son Luong Ngoc <sluongng@gmail.com> writes:\n\n> On Mon, Apr 19, 2021 at 02:52:16PM -0700, Junio C Hamano wrote:\n>> \n>> Interesting.\n>> \n>> I recently had a similar experience with Gerrit, where a patch I\n>> have seen quite a few times on Gerrit at $WORK had an embarrassing\n>> syntactic issues I did not discover until it hit the public mailing\n>> list.  It may be different from reviewer to reviewer, but at least\n>> to me, e-mailed workflow forces me to apply the patch to my tree\n>> before I can say anything non-trivially intelligent about it and\n>> once applied to the tree, it actually let's me play with the code\n>> (like, say, asking the compiler to give its opinion on it).\n>> \n>\n> I think this is very much the point of having a good CI pipeline:\n>   - Apply patches into tree\n>   - Compile\n>   - Run relevant tests\n\nIt is true that CI can spot -Wdecl-after-stmt, but CI only covers\njust one part of what is needed while I do my reviews.  It would\nalso be doable with web interface to look at all the places that\nfunctions modified by the patch are referred to, and to check if the\nchange makes sense in the context of the entire tree.  It would also\nbe doable with web interface to looking at the evolution of the code\nbeing changed.  There are some things, like building and using for\neveryday life, running the built binary under debuggers, etc., that\nmay be harder to do with web interface, but I am sure many things\nwould become doable given enough time and effort.  However.\n\n> Yes, having context beyond the diff is very important for Code Review.\n> This is why I strongly recommend SourceGraph usages to folks I know.\n> ...\n> So I guess mordern toolings are available for these usecases, but\n> fragmented and subjective to personal workflow.\n\nMy point in the message you are responding to was that I can do all\nwhat is necessary locally, with my favorite toolset, once I apply a\npatch to my tree.  The only thing that Gerrit allowed me to skip in\nmy recent adventure was to download the patch and apply to a newly\ncreated topic branch locally to my tree, before I can start doing\nsome of the things (e.g. \"look at the patch, examine with larger\ncontext as needed\", \"grep for the symbols at the same revision in\npaths that are not touched by the patch\") that was needed to review.\nAnd while I know I shouldn't blame the tool for this, but it did\nmislead me to false sense of \"I've reviewed this change well enough\",\nwhen I haven't.\n\nBy the way, I've been playing with \"b4 am\" and it's been a pleasant\nexperience so far.\n\nThanks.\n"},{"id":"422700","messageId":"6081db1246a7_127f620886@natae.notmuch","threadId":"52103","inReplyTo":"20210419203327.GV2947267@szeder.dev","subject":"RE: Pain points in PRs [was: Re: RFC: Moving git-gui development to GitHub]","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-04-22T20:22:42Z","receivedAt":"2021-04-22T20:22:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"SZEDER Gábor wrote:\n> On Wed, Nov 20, 2019 at 09:13:04AM -0800, Elijah Newren wrote:\n> > > On Wed, Oct 30, 2019 at 7:21 AM Elijah Newren <newren@gmail.com> wrote:\n> > > > Projects which switch to GitHub tend to have overall commit quality go\n> > > > down IMO, because the system (a) makes it nearly impossible to review\n> > > > commit messages, so people eventually degrade to writing really bad\n> > > > ones,\n> > > What do you mean here, exactly? In what way is it \"nearly impossible\"\n> > > to review commit messages in GH?\n> > \n> > My lengthy rant wasn't good enough for you?  ;-)  Well, I'll try even\n> > harder to bore everyone to death, then and extend my rant a bit...\n> \n> Thank you very much for taking the time and effort to write it up.\n> \n> It summarized some of my main gripes with PR-based collaboration on\n> GitHub with such clarity that I would never been able to achive.\n> \n> (The recent \"Pain points in Git's patch flow\" thread reminded me that\n> I saved this message and even marked it as important ages ago... but\n> haven't gotten around to read it until now.\n> \n>   https://public-inbox.org/git/YHaIBvl6Mf7ztJB3@google.com/T/\n> )\n\nPeople in general follow the path of least resistance; if you make X\nharder, people will spend more effort doing X, but they will do less of\nit.\n\nPeople have been using email for decades, and there's all kinds of tools\nfor dealing with it (I for example am using a free provider [Gmail], a\ntool to download part of my mails [mbsync], another tool to index it\n[notmuch], yet another tool to read it [notmuch-vim], yet another tool\nto write a response [vim], and I will be using another to send it\n[msmtp]). Or I cound simply use the Gmail app on my mobile phone.\n\nEmail is extremely convenient.\n\nSince it's easy to reply, people do reply, often.\n\nWhich is why it's not rare at all that a patch series becomes a\ndiscussion thread, which are easy to deal with through email.\n\nGitHub adds a layer of inconvenience, so people tend to avoid big\ndiscussions in a GitHub pull request. It's just not fun.\n\nI also did a blog post explaining why email is just superior [1].\n\nTwo other points that were not mentioned that make email superior is\nthat 1) you can easily cross-post, simply CC another project and that\ndiscussion spreads 2) it scales for projects that don't use GitHub; you\ndon't need an account anywhere, and usually you don't need to subscribe\nto post in the mailing list.\n\nIt's no coincidence that the most successful project in history (Linux)\nuses email to deal with contributions: nothing else comes even close.\n\nCheers.\n\n[1] https://felipec.wordpress.com/2010/01/19/why-bugzilla-sucks-for-handling-patches/\n\n-- \nFelipe Contreras"}]}