Re: RFC: Moving git-gui development to GitHub

[Elijah Newren <newren@gmail.com>]

On Sat, Oct 26, 2019 at 11:25 AM Jakub Narebski <jnareb@gmail.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
> > On Thu, Oct 24, 2019 at 2:45 AM Pratyush Yadav <me@yadavpratyush.com> wrote:
> >>
> >> I recently had some discussions with Dscho about whether it is a better
> >> idea to use GitHub for development instead of email [0]. His argument
> >> was that GitHub makes it easier for newcomers to contribute, since more
> >> people are familiar with GitHub compared to mailing lists. Also, it is
> >> somewhat difficult to set up an email-based workflow.
> [...]
> > GitHub is great for ease of creating new repos, learning about other
> > developers, finding similar projects, creation of webhooks, etc.  But
> > it's *awful* for code review.  Gerrit is a lot better at code reviews
> > (though still has problems); so maybe dealing with both GitHub and
> > Gerrit would be reasonable.
> [...]
> > Email is a horrible medium for sending/receiving
> > changes, but at least it gets the overall code review model right
> > (commit-messages-are-first-order-objects-that-can-be-reviewed,
> > review-individual-commits, merge-per-topic, cover-letter included,
> > range-diff for high-level comparison of different iterations,
> > reversing-commit-order-display-based-on-author-timestamps-is-NOT-forgivable,
> > Change-IDs-are-ugly, magic-refs-are-disgusting, etc.), something no
> > GUI tool (yet) does to my knowledge.
>
> I agree with that.  You need then to decide whether it is better to have
> it easier for beginners to contribute, or is it better to have it easier
> to review code.  What are the pain points?

I don't think that's the right comparison to make.  The problems with
GitHub code review aren't solely ease-of-use issues, they are more a
quality-of-code issues.

Projects which switch to GitHub tend to have overall commit quality go
down IMO, because the system (a) makes it nearly impossible to review
commit messages, so people eventually degrade to writing really bad
ones, (b) makes it nearly impossible to review a rebased set of
changes except redoing the entire review from square one, so people
don't rebase, (c) punishes both users and reviewers who want to work
with a rebased patch series by displaying the series out of order --
even for a completely linear history (it resorts based on author
timestamp, not even committer timestamp), and (d) punishes
reviewers/users when they attempt to review individual commits by
making it harder to see and follow these comments (though it has
gotten much better on this front).  There are combination effects too.
People to write really bad commit messages for all the additional
"fixups" they have.  People notice that commits don't bisect nicely,
and instead of understanding that the broken code review system they
wrote was the problem, they instead offer a new "squash merge" option,
thus destroying all the carefully separated commits that help people
understand the individual steps toward the new feature and making it
impossible for anyone in the future to review it incrementally.  You
may say it's a workflow choice for some people to just squash all
their stuff together at their option, which would be fine, but the
problem is most developers don't take the time to think, and someone
in charge of the project notices that they keep getting un-bisectable
meaningless commits unless they force *everyone* in the project to use
squash merging.  Now they are punishing me for creating clean separate
commits and forcing them all to be squashed -- all as an ugly
workaround to the basic tool being *broken*.  You can work around this
by making a long sequence of PRs, one per what you intend to be a
commit, and try to track the hierarchy -- something that GitHub
certainly doesn't make easy.  And then each PR becomes a trivial small
change, and you are back to merging individual commits, and writing
your own tools to manage a hierarchy of PRs...and reviewers hate you
if you do that because it's extremely onerous on them.

GitHub PRs aren't just hard to use, they literally degrade the quality
of the code for people who have to use it.  I've seen it happen with
many projects.

(At $DAYJOB, they have hundreds of repos and have at times used SVN
then gitolite then gerrit then (Atlassian) stash then github (with
other review tools like sourcegraph and reviewable tried and a few
others read up on), with most of those existing simultaneously --
though we eventually pruned it down to just Gerrit and GitHub, with
some projects in one and some in the other system.  I've seen
migrations between various combinations of these tools (though SVN and
gitolite were nearly phased out by the time I joined), and seen
results of how the tools caused differences in behavior.  And yes, I
know that GitHub's popularity means many have copied GitHub's PR
model, from sourcegraph who were basically identical, to Stash which
is similar but handled rebases better, and I think GitLab looks
similar though I haven't used it that much (yet).  Reviewable handled
rebases a lot better, but still used the utterly broken model of not
allowing commit messages to be reviewed -- and glitterbombed the
interface with butterflies.)

> Another source worth looking into is "Patches carved into stone tablets,
> why the Linux kernel developers rely on plain text email instead of
> using “modern” development tools." presentation by Greg KH from
> 2016[1][2].  But remember that git-gui is not Linux kernel; what works
> for one might not work for the other.
>
> It is unfortunate that we have no tools described in "Patches carved
> into developer sigchains"[3] wishfull blog post by Konstantin Ryabitsev...

Interesting links; thanks for providing them.  And yes, I agree that
git-gui won't necessarily have the same tradeoffs as the Linux kernel.
But I do tend to be noisy here hoping I can spark someone with a
modicum of talent for front-end development (I have neither the talent
nor the inclination for web development) to write a sane webby code
review system.  Much of GitHub is awesome.  And it has some apparently
really nice thing for web devs, which seems to be part of why so many
people use it.  It's just so terribly awful at code reviews.  But
systems like Reviewable and GerritHub build on top of GitHub, so maybe
there is hope someone can build just the review part and make it
awesome.

> [1]: https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/
> [2]: https://www.slideshare.net/ennael/kernel-recipes-2016-patches-carved-into-stone-tablets
> [3]: https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains
>
> Regards,
> --
> Jakub Narębski