One disadvantage to pull requests (aka merge requests) is lots and lots of merge commits.
It’s not the worst thing, but it does clutter the commit logs, and make for lots of unnecessary non-sequential history.
A - C - E - G
/ / /
B D F
What I think would be better is to cherry-pick the commits.
A - B' - D' - F'
Of course I can do that myself, but one of the advantages in a pull request system like Github, Bitbucket, Stash, or Gerrit is the ability to do this through the interface, immediately following a review of the changes. And doing that manually wouldn’t show the pull request as accepted in the UI.
Why don’t pull request tools offer “cherry-pick requests”?
I understand the advantages of merges and non-sequential history in the general case. (Otherwise, I’d be using SVN.) I am specifically taking about one or two commit changes from transient branches. (Many tools even help you delete the branch right after merging.) A one-commit change is probably the most common case for pull requests.
6
The thing about pull requests is that it makes known that there are changes that someone wants to bring into the project.
If the owner/maintainer wants to cherry pick parts of the pull request, they can do that from that pull request.
And just because there is a pull request does not mean that the maintainer is not allowed, or incapable, of doing a rebase.
So this is indicative of a style that may be wanted in the history.
You can always display the history without the merge history, or even the other way around.
git log --mergesgit log --no-merges
So it boils down to, I think:
- The project owner wanting to enforce, or not, a certain style of history
- The fact that you can get either set of information easily from Git itself, regardless.
You also mention that “A one-commit change is probably the most common case for pull requests” but I am not sure about that.
For one, the number of commits may be unknown due to the developers habits of doing micro-commits and then rebasing them. Also, it is common for me to see project owners asking for those commits to be squashed in the CONTRIBUTING.txt file, or other communication.
Edit: Of course, I can’t answer the question of why doesn’t X, Y and Z companies do something. Not sure anyone can, except for those entities.
4
I think there are some points to consider:
- Forge-focused development (pull requests)
- Using merges to mark where features where incorporated
- Rebase as cherry-picks
- Not wanting to change incoming commit messages
I think many projects that use Git can get very forge-focused. Meaning
that they end up using the information in the forge-only pull request
link.
The standard merge message is convenient for that:
Merged xzy into `master` (PR #789)
Now if you’re viewing the commit in some forge’s webapp then #789
could be a hyperlink to the pull request. And if the merge commit
message is nothing more than that line then they might need to open the
PR in order to view the description and the discussion.
Squash merges
The pseudo-merge variant “squash” also acts like this since they can be
also written as “Merged …”, i.e. with the same kind of information.
Rebase as cherry-picks
Arguably cherry-picks are an option on forges that allow you to
incorporate a pull request by way of a rebase + fast-forward.
Not wanting to change incoming commit messages
We’ve already talked about how merge commits can be used to add metadata
to an incorporated branch. In contrast, there is no culture for changing
commit messages in forge-based workflows.
I don’t mean changing the commit message proper but adding or modifying
metadata in the form of trailers.
Some projects, like the Git project, use a patch-based workflow with
signoffs. Which means that both the developer signs off the patch
when they send it out:
Implement X
Signed-off-by: John Smith <[email protected]>
And the integrator as well when they import the patch from their
mailbox:
Implement X
Signed-off-by: John Smith <[email protected]>
Signed-off-by: Jane Underhill <[email protected]>
These trailers are also used for other kinds of metadata about the
review process:
Implement X
Signed-off-by: John Smith <[email protected]>
Tested-by: Hobsbert Fedora <[email protected]>
Acked-by: Frank Wall <[email protected]>
Signed-off-by: Jane Underhill <[email protected]>
In this way, each patch (a future commit) can get their own metadata.
I haven’t seen any culture for this in forge-based (read: PRs)
workflows. But I see no reason why commits can’t be cherry-picked with
metadata about whence the PR:
Implement X
Pull-request: #654
Conclusion and personal opinion
Personally I prefer true merges on my own multi-commit pull requests. On
single-commit PRs I do prefer what is effectively a cherry-pick, since I
use a “squash merge” for those if I’m the one who is incorporating the
change.
But sometimes I want to make a small PR on top of another person’s
PR. For such smaller PRs I think this cherry-pick idea is nice, and that
creating a true merge is often overkill (and distracting). Then a
cherry-pick (or rebase) with some metadata about the provenance of the
change would work great, I think.
Include Y in X as well
Pull-request: #4935
Good question by the way.