On Fri, Apr 28, 2023 at 4:17 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> [ ... ] I explicitly choose to use fine
> grained merges for that series to retain all the context/cover
> letter information for each part of the series that Darrick had
> included in the tags for his pull requests. While it means there are
> lots of merge commits, it also means the context and some of the
> reasoning behind the series of changes is kept in the git tree with
> the rest of the code history.
Oh, absolutely no complaints about *these* kinds of merges.
These are lovely, and clarify history rather than obfuscate it. And
the merge messages are extensive and explanatory too.
So yes, I often complain about pull requests that have merges in them,
but that's because of sloppy merges that make no sense and only make
things harder to follow and understand.
Merges per se are not bad, and these all act as nice "punctuation" for
the development. It's the ones with no explanation and no logic to
them that I so detest and try to actively discourage.
Linus
