Re: [PATCH v1] Configure Git contribution guidelines for github.com

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> There are things we get out of this that would regress if
> submitGit were changed this way:
>
>  * Now when you submit a pull request you get a Travis build for
> git/git, I don't get this if I push to any random branch in my
> avar/git, and although I could probably set it up, it's extra work
> etc.

Thanks for pointing this out.  I agree that this indeed is a
downside.

>  * I like being able to "git fetch" patches I'm reviewing. Now I can
> just set "+refs/pull/*:refs/remotes/origin/pull/*" in the refspec for
> git/git, if it were pulling from target repos I'd need to "git remote
> add" for each one, not a big deal, but less convenient.
>
>  * There would be no single place to list submitGit requests, which
> you can do now through the pull page, although I think this is largely
> stale now because nothing auto-closes them if they're merged (by which
> point they'll have different sha1s), but that could be improved with
> some bot...

I do not think these two are 'regressions', unless your definition
of 'regression' is a "this thing I used to be able to do, now I no
longer can", which is slightly different from mine, which is "this
useful thing I used to be able to do, now I no longer can".

It would be useful to be able to do the above two things, if the
list of submitGit requests and what you can get from pull/*
hierarchy (1) covered most of the changes proposed, allowing people
to check only this place and nowhere else, and/or (2) covered the
more interesting changes that are worth looking at than other
proposed changes.

I do not think either is the case.  The submitGit mechanism being an
easier way to propose a change to the mailing list, by definition,
(1) will not hold true.  And among the changes proposed to be made
to Git, the "selection criteria" to be in the set to be discoverable
by going to github.com/git/git.git and checking the submitGit pull
requests is not that they are of higher quality or touch interesting
topics.  The only common trait these proposed changes share, compared
to other proposed changes we see on the mailing list, are that they
were originally made as pull requests and (2) will not hold true.

Another thing that may regress that you did not mention is that we
would lose a convenient way to _count_ proposed changes coming via
submitGit (i.e. you can simply go to the pull-request page), so that
the number can be compared with the number of proposed changes
directly made on the mailing list, which would be a good way to
gauge how submitGit service is helping our community.  But even for
that, you'd need to go to the list to find the denominator
(i.e. total number of changes proposed), and by the time you do
that, counting the numerator (i.e. those come via submitGit) by
finding the telltale sign submitGit leaves in its output among these
denominator messages should be trivial.

So in all, I see the only downside is the loss of automated
triggering of Travis.  But I do agree with you that it is a rather
significant downside.

> There's probably ways to do this without git/git pull requests, but I
> don't see what problem would be solved by moving this off git/git,
> even if there's open requests submitGit is the only thing using these,
> and any confusion about that pull UI would remain if it wasn't (AFAIK
> there's no way to completely disable pull requests on github, but I
> may be wrong).

Hopefully the pull-request template update Lars proposes will keep
the pull request useful, in that they create one and then have
submitGit relay it to the official channel.