7

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.

  • related: stackoverflow.com/questions/1241720/… – Simon Bergot Sep 20 '14 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? – StarWeaver Sep 20 '14 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. – gbjbaanb Feb 16 '16 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. – Paul Draper Feb 16 '16 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. – gbjbaanb Feb 17 '16 at 8:37
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.

  • 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. – Paul Draper Dec 4 '14 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. – vgoff Dec 5 '14 at 18:38
  • 2
    tool meaning the website. Git + email can of course do anything one could ever want. – Paul Draper Oct 26 '17 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. – vgoff Oct 27 '17 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.