Michael Blocksome <[email protected]> writes:

Furthermore, whether or not a cherry-pick is even needed depends on if the "source" branch has been completely rebased to master or not. If not, then the commit needs to be changed in the process of moving to master (which resets the committer), but if it is a strict fast-forward of master then the commit is not altered (committer remains the same) and the HEAD pointer of master is merely moved to point to the new commit.

This is not true with git cherry-pick, unless you explicitly pass --ff.

It seems to me that what you really don't like is the "rebase" style of git workflow and would prefer a "merge" style instead?

I like topic branches, but that is neither here nor there, and even with topic branches, the commit doesn't enter the repository (or doesn't start to be integrated) without discussion in which it acquires Reviewed-by/Acked-by tags (and Signed-off-by for projects using a DCO).

Whether some commit says "Signed-off" or "Reviewed" or nothing is really not a big deal - as long as the convention is documented by the community and followed.

Not a big deal, just document it if you're going to use it differently than every other project. It's not my decision and it's not important to me; I only intended to point out the lack of documentation and the usage inconsistency relative to the intent of the Git developers and the convention used by thousands of developers of high-profile projects (influencing tooling and dominating search results).