8

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.

Improve this question
6
  • related: stackoverflow.com/questions/1241720/… Commented Sep 20, 2014 at 6:33
  • I haven't seen what these histories look like but I'd think that having a clear display of merges being from externvl sources would be preferable in many cases? Commented Sep 20, 2014 at 9:29
  • 1
    you obviously don't understand the tools, or you'd be using SVN where merging and cherry-picking is very easy. SVN also 'collapses' merge histories to keep a clean history unless you want to see the components of a merge. Perhaps you should use SVN instead of being sarcastic. Commented Feb 16, 2016 at 8:59
  • 1
    @gbjbaanb, I don't lack the ability to merge or cherry-pick, but rather the ability to cherry-pick through a distributed code review tool (e.g. think Github's pull requests). I don't mean to disparage SVN or any other non-DVCS; rather I just wanted to point out that I am using Git because I value non-sequential history in some cases. Commented Feb 16, 2016 at 22:52
  • @PaulDraper fair enough, but if this isn't a git question the answer is probably because different tools tend to work with lots of different SCMs, and cherry-picking from the interface is possibly too much trouble to support. For example, I recall Redmine not supporting a date-range of commits because their git interface was set up to handle guid-based revisions rather than dates.I think your question could be rephrased to reflect your query about tools on top of git. Commented Feb 17, 2016 at 8:37

2 Answers 2

Reset to default
4

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 --merges
  • git log --no-merges

So it boils down to, I think:

  1. The project owner wanting to enforce, or not, a certain style of history
  2. 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.

Improve this answer
4
  • 1
    "just because there is a pull request does not mean that the maintainer is not allowed, or incapable, of doing a rebase"...I already stated that in my question. The difference is that the tool can't do it, which makes it more tedious. Commented Dec 4, 2014 at 21:38
  • The tool, meaning the website? Or the tool meaning git? Git can do it, and yes, I realized you did mention that "you" could do that yourself. I mentioned the maintainers, rather than I assume your role as a contributor. Different perspective was assumed, I think, when I read your assertion. Commented Dec 5, 2014 at 18:38
  • 2
    tool meaning the website. Git + email can of course do anything one could ever want. Commented Oct 26, 2017 at 16:15
  • I think the only way to know this is to ask the developers of the "tools". I don't think it can be answered otherwise. My answer, is only skirting the question asked, of course. Commented Oct 27, 2017 at 13:10
0

I think there are some points to consider:

  1. Forge-focused development (pull requests)
  2. Using merges to mark where features where incorporated
  3. Rebase as cherry-picks
  4. 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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.