Stop merging if you need to cherry-pick

The VSTS team wrote a response to my series from a few months ago titled Stop cherry-picking, start merging.

Stop merging if you need to cherry-pick

As the stewards of Visual Studio Team Services's Git server, we read Raymond's stop cherry-picking, start merging series with great interest. When Raymond pays attention to your area, you should probably pay attention to what he has to say. After finishing the series, we both agree and disagree with his conclusions.

Given the constraints Raymond's team works under, we think he's found a pretty good solution to some very real problems. Windows, for historical reasons, has a lot of long-lived branches that need to merge into each other pretty often. If you need to fast-track a fix from one branch into another ahead of the official integration schedule, you're definitely setting yourself up for the kinds of conflicts Raymond writes about.

But... if you aren't Windows, you probably don't have this problem. Over in VSTS, we use and recommend a trunk-based development model with few long-lived branches. While our "Release Flow" model does include servicing branches for some releases, those branches will never merge back together. Thus, we don't encounter the merge conflicts and silent work reversions that Raymond's team does.

In a way, the solution is almost as painful as the problem. You have to know ahead of time what branches you're going to cherry-pick your commits into. If you don't, you can make quite a mess of your Git graph. And if anyone on your team doesn't fully understand the history contortions this workflow involves, they can mess it all up for you. For those reasons, and because we expect it's rare outside of Windows's workflow, we don't plan to put any features into VSTS to automate this.

One other note: think twice (or maybe three times) before you git merge -s ours under any circumstance. While it's the right thing here, you're intentionally throwing away someone else's work. We've fielded innumerable customer tickets of the form, "Git lost my work". In the vast majority of cases, the culprit was someone resolving merge conflicts by throwing away work. Git didn't lose your work — you asked it to forget your work!

Thanks to Raymond for writing this series, and for allowing us to pile on. The Windows team has been a great partner in helping us make our server (and indeed all of Git) scale to insane sizes and workflows. We're always considering new approaches to Git which might be applicable to the wider community.

I extend my thanks to the VSTS team for providing their perspective.

As the VSTS team notes, the problem case is where you cherry-pick between two branches that will eventually merge. If the two branches never merge, then there's no need to get all fancy with your cherry-picking.

Comments (14)

  1. It appears someone on the Office team issued a “git merge -s OneNoteUWP”, throwing OneNote 2016 away. 😉

    1. xcomcmdr says:

      And the world was a better place.

      1. Mark S says:

        Yeah, how? As usual there are a bunch of features missing in the “modern” replacement.

      2. It depends. Lots of OneNote clones are being announced, promising users not having to put up with the new UWP thing. Clearly, Microsoft has bled and sharks want a piece of its market share.

  2. JAS says:

    Why did you guys run to Git rather than build up your own compelling source control behemoth? You don’t need the code on that site, it’s all garbage.

    1. Simon Clarkstone says:

      “You don’t need the code on that site, it’s all garbage.”
      Which site do you mean?

    2. xcomcmdr says:

      You’ve reviewed ALL the code on GitHub ?

      What a guy !

    3. First, they did build their own behemoth. That behemoth is now 28 years old.

      Second, Git and GitHub are two different things. One is a back-end, the other is a website.

  3. AMX says:

    That one sentence almost looks like they are trying to imply the Windows team is using an insane workflow. o.O

    1. James Moore says:

      In the nicest possible way, in a way that only coworkers can provide.

  4. alegr1 says:

    >”Git lost my work”

    The beauty of Git is that everything stays there forever, nothing is lost for good. Even orphaned commits are kept there for 90 days by default, before the garbage collection discards them, and you can find the history of amends and rebases in the reflog. Work lost in a merge? Do the merge again with the correct parameters, then use the merged tree for the new commit (git read-tree). MAKE SURE TO ONLY MERGE ON A CLEAN TREE. –abort will not restore back to the original dirty tree.

    1. Mark S says:

      Sure sounds like your last sentence contradicts your first…

    2. Jaloopa says:

      >everything stays there forever

      >the garbage collection discards them

      >abort will not restore back to the original dirty tree

      Everything stays there forever except the things that only stay for 90 days or the things that don’t stay at all

  5. DWalker07 says:

    Those links, in the paragraph that starts with “But…”, are extremely helpful.

Skip to main content