On 02/28/2017 10:04 AM, Vladimir Panteleev wrote:
On Tuesday, 28 February 2017 at 14:52:36 UTC, Andrei Alexandrescu wrote:
Thanks. I'd replace "changes should be split into as many commits as
is reasonable" with "changes should be split into as many pull
requests as is reasonable", which is a natural consequence of "most
pull requests should consist of one commit upon merging". (Of course
there may be several commits during PR review.)
Well... not always. For example, introducing a private function that is
not called from anywhere is something that doesn't really make sense as
a pull request of its own, but does make sense as a separate commit.
One vs. several commits per merged pull request is a matter in which
reasonable people may disagree, and we can't do both ways. The
Foundation fosters that github pull requests are squashed upon
merging, with exceptions that need to be justified.
Sorry, but I don't think that's reasonable at all.
I have seen no arguments to support this way of doing things, only
downsides. Established major projects seem to agree.
As far as I can see, this is not about a subjective point regarding
which reasonable people may disagree. It seems to be a poorly justified
mandate, that's all.
As I've mentioned previously, you will need to provide some arguments
which would outweigh those supporting the opposite position.
There can be any amount of discussion about this, to no conclusive
results, and any argument may be responded with "I don't buy that".
That's simply because, again, there's some subjective factor and there
is no perfect approach that proves the others wrong. To wit, I have
stated my argument several times in public and private but somehow it
did not count.
Here we are simply applying a way of doing things that has worked at
Facebook over six years and two orders of magnitude increase in team
size. (They use phabricator there, which has a similar workflow.) It is
obvious to me that other organizations use similar approaches; and also
that other organizations use different approaches, also with good
results. I should add that Facebook is one of the most successful
software companies in history, and that may count for something.
Also, obviously the Internet can be used to find support for anything,
and with that caveat allow me:
* "Why does every serious Github repo I do pull requests for want me to
squash my commits into a single commit?"
http://softwareengineering.stackexchange.com/questions/263164/why-squash-git-commits-for-pull-requests
* "I’ve been contributing to more projects in which it is expected that
I should submit a pull request that contains a single commit."
http://ndlib.github.io/practices/one-commit-per-pull-request/
* "Squashing your branch's changes into one commit is "good form" and
helps the person merging your request to see everything that is going
on." https://github.com/projecthydra/hydra-head/blob/master/CONTRIBUTING.md
* "But one thing occasionally bothers me, and that's pull requests that
come loaded with several temporary commits. I often find myself asking
contributors to squash those into a single descriptive commit."
http://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit
I'll stop here. Sure enough, there'd be other links to pages describing
how many commits per PR work fine. Our organization happens do things
this particular way, and it's not the only one. Moreover, we are are not
rigidly enforcing it; within reason, definitely leeway exists.
Vladimir, I am gathering that this makes you unhappy and are close to
getting ultimative about this. I have made all attempts I could to
publicly and privately explain matters. I kindly ask you to consider the
following:
* Any organization, be it for profit (company) or not (university, oss
project) has certain rules in place. In all likelihood not all
participants would choose the exact same rules if they could, yet they
choose to walk (factually or virtually) in there every day and
contribute to the organization. A simple way to look at things would be,
would you quit a job or start a protracted argument with the CEO if the
coding guidelines contained "please squash your github commits"?
* The leader of an organization (in this case me) cannot afford the time
to justify and debate every single minor decision they make. No
organization works that way. I am under enormous pressure to bring money
in the Foundation, organize DConf, mentor students, write articles,
contribute code, all while keeping things running.
* You seem to frame things as an arbitrary imposition made by an
oppressive leadership. Think of it - ever since we have worked together
(your first post is dated 2007-01-06!), is this the pattern by which
matters have been conducted? Do you think it would be a fair
characterization of Walter and my philosophy and values?
The short of it is we simply cannot work this way, as a simple matter of
my own human limitations; I can't spend hours in the forum justifying
every little thing, especially those that ten people do in eleven ways.
I mean I _literally_ can't: I don't have the time because I am spending
it making the D language more successful. Which I hope you'll help me
with, too. To scale, we need to focus on the real problems and abandon
debating the small things again and again.
Thanks,
Andrei
