Re: Multibyte support for sort, uniq, join, tr, cut, paste, expand, unexpand, fmt, fold, and pr

[Kaz Kylheku (Coreutils)]

On 2018-03-20 15:18, Assaf Gordon wrote:
> Two things for later (not critical for now):
> to make review easier, it's recommended to combine all commits that
> relate to a single program
> into one commit. This is called "squash" in git (see:
> http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

All little commits that achieve one logical change should be squashed.
For instance, don't have

   239d4f9 foo: implement feature X.
   3df77ab foo: fix missing semicolon in new X.
   93df301 foo: fix null pointer deref due to X.

These little incremental fixes in the development feature X shouldn't be
published as separate changes; only the polished, debugged, reviewed 
"feature X".

However, changes pertaining to different development "topics" should
never be squashed into one commit.

Two commits being to the same program in GNU Coreutils are not 
automatically
the same topic.

E.g. these would be wrong to squash together:

   100df03 ls: implement quoting for whitespace.
   69d34d0 ls: fix bad indentation in several functions.

Review is certainly not easier when multiple changes are combined.
I don't want to review some change in logic, under the distraction of
numerous whitespace changes, or changes in unrelated logic.

> https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits/
> ).

That is just lunacy. Certainly, you should cleanly cherry pick or rebase 
all changes
onto a single mainline without a crazy merge graph: that much of it is 
true.

Squashing all changes is poor.

"Patch bombs" (big changes that combine multiple topics in one diff) 
will
not pass review in any shop that understands version control.