Does cherry-pick just pull changes into the current working tree as uncommitted changes?

Question

My team uses Mercurial for version control. Our development / version control routine is:

1. all been committing to the same branch
2. pulling for changes and rebasing our commits locally before pushing back to the hosted repository

This keeps everyone in sync. And the latest code (even unfinished code) is than grabbed from the tip of this branch and put into our test environment.

I've been tasked with creating a management process where we can more cleanly extract "completed features" into the test environment.

I've advocated that we begin to branch->pull-request->merge->close branch process, but I've been told that branching is not an option, and that the project director would prefer too be able to manually select commits representing completed features/bug fixes and only include those commits in a deployment to testing.

I am not sure what terminology besides cherry-pick in GIT / HG that would represent this process, and if it would even be advisable as the commits would no-longer have a proper revision history as it's my understanding that cherry-pick just pulls changes into the current working tree as uncommitted changes correct?

Answer 1

1. Cherry-pick for Mercurial is hg graft
2. History of grafted commits are easy recoverable, especially if graft performed with --log option and without --edit+madcap editing commit-message. Also the good GUI (TortoiseHG) reveals the history of grafting.

Toy-repo with some grafting in it (release+devel branching model)

Glog ouput in console:

hg glog --style changelog
2015-08-05  Author <email>

@       * c.txt, cd.txt:
|       Cnange 4
|       [769d5ba1b198] [tip] <release>
|
o       * c.txt:
|       Cnange 3 (grafted from 3044bbf6fe3542b86d0a1a84b7455d76928b559b)
|       [e58f524b1203] <release>
|
o       * a.txt:
|       Cnange 1
|       [23d4aaf0c632] <release>
|
o       * Release branch created
|       [9f39dda2e0d9] <release>
|
| o     * c.txt, cd.txt:
| |     Cnange 4
| |     [c5523fade515]
| |
| o     * b.txt:
| |     Edit 2
| |     [7efeb998f47e]
| |
| o     * a.txt:
| |     Edit 1
| |     [4f2e0bffed8a]
| |
| o     * c.txt:
| |     Cnange 3
| |     [3044bbf6fe35]
| |
| o     * b.txt:
| |     Cnange 2
| |     [278066927656]
| |
| o     * a.txt:
|/      Cnange 1
|       [e233699bf798]
|
o       * .hgignore:
        Initial structure
        [3bf949e66c66]

(grafted changesets 1,3,6. Only changeset 3 grafted with --log added. Note unchanged commit-message for 1 and 6)

and this repository after all grafting in TortoiseHG

Answer 2

I'm not sure about mercurial, but git cherry-pick will create a new commit to contain the changes unless you tell it otherwise. The crucial point is that it detaches the commit from its history, including any commits it depends on for proper operation. That also makes it a pain when you have to merge testing changes back into the development branch, and makes it difficult or impossible to use built-in version control tools to do just about any useful comparison you'd want to do between testing and develop, including simple questions like "Did that bug fix make it into testing?"

I would find out the reasons behind branching not being an option. Perhaps they are basing it on a previous bad merging experience in a subpar version control system (pretty much all of them were bad at merging before hg and git came along, and a lot still are bad).

I would sell feature branches as being able to select commits containing completed features together with all required dependencies, while always maintaining the ability to track and compare between development and testing. cherry-pick is useful to correct the occasional exceptional circumstance that your branching model didn't account for, but using it as the total basis for your configuration management is asking for trouble.