Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 8273 bytes --]

Hi Kuba,

On Sun, 28 Aug 2016, Jakub Narębski wrote:

> W dniu 25.08.2016 o 15:21, Johannes Schindelin pisze:
> > On Mon, 22 Aug 2016, Jakub Narębski wrote:
> >> W dniu 22.08.2016 o 15:18, Johannes Schindelin pisze:
> >>
> >>> So unfortunately this thread has devolved. Which is sad. Because all
> >>> I wanted is to have a change in Git's submission process that would
> >>> not exclude *so many* developers. That is really all I care about.
> >>> Not about tools. Not about open vs proprietary, or standards.
> >>>
> >>> I just want developers who are already familiar with Git, and come
> >>> up with an improvement to Git itself, to be able to contribute it
> >>> without having to pull out their hair in despair.
> >>
> >> What is lacking in using submitGit tool for those that have problems
> >> with sending patches via email?
> > 
> > Where do I start? And where do I stop? Here is a *very* brief list of
> > issues from the top of my head (and the history of my web browser):
> 
> Let me reorder those issues and group them into specific categories.

I am afraid that this is not the direction I was interested in.

You asked how submitGit fell short of my goal to provide a more convenient
and more efficient submission process, and I listed a couple of reasons.

I am really more interested in a better process, than in a point-by-point
discussion of the reasons I listed.

And some of those discussions really only distract. This comment, for
example, seems to be designed to veer off in a direction that, quite
frankly, does not matter for what I *really* wanted to discuss:

> > - submitGit requires you to go to a separate website to interact with the
> >   submitGit web app. Would be so much nicer if it were a bot operating on
> >   PRs.
> 
> [...]
> 
> Also, for some people registering on GitHub is "yet another service"... ;-)

I am really curious how this is supposed to keep the discussion rational.

*Of course* I implied that it is bad enough to require contributors to
register with one web service, and that requiring to register with *yet
another service* is just excessive.

Sheesh.

> > - You cannot Cc: people explicitly:
> >   https://github.com/rtyley/submitgit/issues/31
> > 
> > - submitGit does not include any interdiff
> 
> These are, I think, mainly related to lack of support for series *iteration*,
> for sending new version of patch series / of pull request.

Yes, of course. Because that is what makes the process so particularly
tedious, thankyouverymuch.

> I don't know how well GitHub pull requests deal with iteration and
> refinement, and what is available as API to apps such as submitGit.

Hmm. Then it may be a good idea if I let you find out before we continue
to discuss these bullet points that I never wanted to discuss.

> > - submitGit would require a substantial effort from me to learn how to
> >   extend/fix it, to run the web app locally and run its tests. That is a
> >   rather steep hurdle.
> 
> Well, you cannot extend/fix GitHub at all yourself, isn't it? ;-P

Sure you can. There is an API and you can register hooks. You can do even
more advanced stuff [*1*].

> >> Submitting changes in Git comes in three phases:
> >>  - submit email with patches
> >>  - review and discuss patch
> >>  - apply patches from email
> > 
> > You forgot a really crucial step. Maybe you did not go through dozens of
> > iterations in your patch series as I regularly do, or something, so it is
> > probably easy for you to forget:
> > 
> >   - find the commit in question, run rebase -i and patch it as suggested
> > 
> > This is something that costs me quite some time to do. It is easily the
> > most annoying aspect of the mail list-based approach for me.
> 
> I probably don't have as many topics in flight, and maybe the number of
> iterations is smaller, but I don't remember having troubles with that.

Well, aren't you lucky.

I bet you did not intend to sound condescending there, even.

> > It is only projects such as Linux, Cygwin and Git itself who refuse to
> > allow for tools that would let the majority of potential contributors
> > stick with their favorite way to read and write mails (I am talking
> > about users of GMail and Outlook, of course).
> 
> Those are projects that started before GitHub (for obvious reasons), and
> which created a good enough workflow based on email.  It might be that
> they are ossified relics, or it might be that they don't want to trade
> advantages of email based workflow for advantages of web app based
> workflow.

Those are projects that started before Git was invented. Yet all three
projects traded the advantages of patches and tarballs for advantages of
using Git.

> First, email clients and Usenet news readers support threading.  I
> haven't found a good web app that supports threading well (though it
> might be a matter of small set of such apps examined by me).  They allow
> marking and labeling posts to return back later.
> 
> Second, email allows offline work, and handle well sporadic Internet
> connection.  As far as I know web apps do not handle breaks in net
> access well, but I might be mistaken.  Hopefully this problem would
> vanish with improving broadband... though there always would be places
> without constant always-on Internet connection.
> 
> Third, email (or rather conventions around email) allows to provide
>  - description of the whole series (in cover letter)
>  - comments for each commit individually (outside of commit message)
>  - make commit or series be a reply to discussion (useful with WIPs)
> For reviewer it allows to
>  - comment on the whole series in response to cover letter
>  - comment on individual commit
>  - comment on the commit message
>  - comment on the description of commit
>  - comment on changes
>  - start a discussion based on a commit
>  - propose improvements as patches

I find these reasons to be more a defense of "ossified practices" than
based in practical considerations.

For example, it is delusional to think that you can do any proper review
of any moderately complex patch without having access to a worktree
reflecting the revision after the patch.

So this entire idea that review is inherently something you would want to
be able to do without having access to a Git repository reflecting the
patches in question is an idea I reject flat out.

For the record, I have used GitHub Pull Requests *extensively*, as
contributor, as reviewer and as maintainer.

The Pull Request web interface has changed over time, but one thing
remained constant: it was always much more efficient to interact with than
going through the mail list.

The commit diff is naturally linked to *the commit*.

If I reply to notification emails when somebody left a comment, it is
automatically turned into a reply on the web.

If I do not want to reply via email, or if I need to see a bigger context,
the notification email has a link which opens the web interface, where I
can easily not only increase the diff context but also see other files in
the same revision, e.g. to check a signature in a .h file.

These are just a few things that are essential to efficient code review,
and that are simply impossible with a mailing list approach, unless it is
opinionated by requiring specific tooling to deal with the fact that code
is transported through a code-hostile medium.

So please understand that I am really interested in more efficient code
review instead of a lengthy philosophical discussions, and that I am
really saddened that I could not gain anything from your mail in that
respect.

I really hope that something constructive comes out of this whole
discussion, because if we simply stick with this unwieldy patch submission
process that costs so much of my time, then I really only lost time for
nothing in return.

Ciao,
Johannes

Footnote *1*: I wrote a little GreaseMonkey script to add a TOC button to
the GitHub wiki editor: https://tomancaklab.github.io/gfm-add-toc.user.js
Similar extensions can be implemented to augment the PR workflow to your
liking, with the advantage of being opt-in.