If we can somehow enforce the rebase before merge, then I think it won’t have the merge “tree” problem. > git checkout -b work master > # commit a change on branch 'work' > git checkout master > git cherry-pick work + git checkout work + git rebase master + git checkout master > git merge work
> On Sep 24, 2015, at 12:59 AM, Chris Hillery <[email protected]> wrote: > > On Thu, Sep 24, 2015 at 12:32 AM, Jianfeng Jia <[email protected] > <mailto:[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 > > <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 > > <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 Best, Jianfeng Jia PhD Candidate of Computer Science University of California, Irvine
