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

["Jakub Narębski" <jnareb@gmail.com>]

Hello Johannes,

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.
 
> - You cannot open a PR on GitHub and include the PR's cover letter as
>   cover letter: https://github.com/rtyley/submitgit/issues/9
> 
> - you have to register with yet another service to send mails on your
>   behalf. Would be nicer if the mails could be sent from a submitGit
>   address (moderated, of course) and did not need a separate registration
>   step with some scary permission granting.
> 
> - 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.

Those are issues about lack of integration (or need for better integration)
with GitHub pull requests.  I don't know if tighter integration would be
possible (without going the route of web browser plugin, like ZenHub) with
current API.  Note that many integrations require you to go and use their
separate site, like e.g. HuBoard.

Also, for some people registering on GitHub is "yet another service"... ;-)

> - 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.

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.

> 
> - it is really hard to get back from mails to the corresponding commits
> 
> - comments sent as replies have no connection to the PR *nor* the commits
>   they refer to (making submitGit basically a pimped up git-send-email,
>   nothing more).

I guess that turning submitGit into two-way bridge between email and PR's
would be quite difficult, if at all possible.  For one, it would have
to parse emails to turn response as email into comment on diff in PR.
For second, I'm not sure if all features of email workflow are possible
to represent in PR's: cover letter, comments for individual commits,
commits about commit messages, commits about changes, free-form comments.
But maybe they are possible; the trouble would be in translating back
and forth.

> - 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

> 
> This is an incomplete list, of course.

Right.

>> 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, when I was most active doung Git development I were using StGit
patch management interface instead of rebase -i; I think it makes things
easier.  Perhaps git-series could replace it, or augment it.

>> Pull request via GitHub / Bitbucket / GitLab is easier than sending
>> patches via email (pity that GitHub et al. do not have such submitGit-like
>> automation built-in).  But I think email, with threaded view, careful
>> trimming of quoted contents, multi-level quotes is superior to exiting
>> web-based solutions.
> 
> They are not exiting, but I know what you meant.

That was a typo: s/exiting/existing/
 
> The thing is: GitHub does not need such an automation. Because most
> projects are pretty happy with the process centered around the web app.

It might be that they don't need features not available in a web app.
It might be that it is only way they know.  Not all projects are happy
to being on GitHub even if they are happy with using hosted git.

And they were probably created after GitHub / GitLab / Bitbucket were
here. Also - citation needed.

> 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.


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

Are all of them possible in PR's?


To reiterate what I have said elsewhere in this thread: while it is
a good idea to lower barriers to contribution, especially for new classes
of users (like MS Windows users, without a way to easily install and
configure MTA so that git-send-email and/or git-imap-send just works,
or with default email client without support for preserving whitespace
and monospace fonts), it is reviewers and maintainers that are sparse
resource.

Best,
-- 
Jakub Narębski