PR final steps (to squash or not to squash)

[René J.V. Bertin]

On Monday December 5 2016 22:52:51 Lawrence Velázquez wrote:

> Fetching from a fork does not download the full history. Only the
> objects that are not in your repository are fetched.

That implies adding the fork as another remote with the associated house-keeping afterwards? If so, I'd still prefer clicking around a bit to fetch a patchfile to create an isolated port directory or tree.

>I daresay I'm the fussiest committer here. Most of us would probably not
>nitpick a submitters' well-edited set of commits.

Not that it's directly relevant to the topic at hand, but how many committers are there? When "most of us" (who don't nitpick) translates to "no one else", a revision process shouldn't be blocked by one or a few "fussy" individuals in an ideal world. It would be very good to get more committers involved in the revision process. I'm not sure how; the peer review process as used in scientific publication comes to mind (oh, the fond memories...), where an "editor" (ideally picked by the author) requests timely reviews from a number of referees. Question is of course who those editors would be, and who'd appoint them.

>It's generally not trivial, no. Editing and revising prose to be clear
>and concise isn't trivial, either.

The real non-trivial problem is to define "clear and concise" in a multi-cultural and multi-educational context and I'm tempted to say that this is so much so that exchanges tend to focus on concise exclusively.
 
>
>> Side-ways related: maybe the Git/PR wiki topic could say a word or two
>> about when a rebase request might be made before a PR can be merged.
>
>Huh?

The how to work with git wiki topic about pull requests ("Updating your fork") states something like "we might ask you to rebase your changes on top of our current master branch". A bit of explanation when and why such a request might occur won't hurt. As it is that subsection suggests one should keep one's fork updated, which apparently isn't necessarily the case (in my cmake-1-1 PR it left traces in the commit history which I've been asked to squash).

R