On Thu, Sep 24, 2015 at 12:32 AM, Jianfeng Jia <[email protected]> wrote:
> I haven’t tried yet, but here is a stackoverflow answer[1] showed that git > can > magically skip the “same” cherry-picked commit even for the rebase case. > Then rebase on there own branches should be fine. > > [1] > http://stackoverflow.com/questions/14509878/why-does-a-rebase-after-a-cherry-pick-not-apply-the-same-commit-twice > Yep, I've seen this work, and I had assumed it worked for this reason. The rebase case is actually easier in a sense because git is replaying commits one at a time. But I'm glad to see this is actually a documented and intentional behaviour. The merge case is more interesting, but it seems like it should work in most cases too: http://stackoverflow.com/questions/14489056/does-git-cherry-pick-save-any-metadata?rq=1 I just tried the most trivial version of this: git checkout -b work master # commit a change on branch 'work' git checkout master git cherry-pick work git merge work That is - cherry-pick a change from a branch (the tip of the branch in this case) onto master, and then merge the branch onto master. Git handled this without conflicts, which to be honest surprised me a little bit. There are two downsides, however, both of which are caused by the fact that the cherry-picked commit is not the same commit: - "git merge" was unable to just fast-forward master; it did introduce a merge commit onto master, which doesn't really serve any purpose - perhaps more annoyingly, "git log" on master now shows the change twice: % git log --oneline -4 3b24414 Merge branch 'work' 6cbf7e3 This is a text change 23bfa31 This is a text change cc4356e CBD-1635: some initial work to run tests once a day The reason for this is clear enough if you use git log --graph: % git log --oneline --graph -4 * 3b24414 Merge branch 'work' |\ | * 23bfa31 This is a text change * | 6cbf7e3 This is a text change |/ * cc4356e CBD-1635: some initial work to run tests once a day This leads me to my main concern / objection to the merge approach: it's extremely easy for this to lead to truly squirrelly log histories on master. That is the main (and perhaps only) clear benefit to the current squash-and-cherry-pick approach we have - the log history on master is guaranteed to be linear, self-contained, and easily understandable. You pay a price for that orderliness, however, in terms of branching flexibility. Ceej aka Chris Hillery
