asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hillery <>
Subject Re: Merging vs. squashing
Date Thu, 24 Sep 2015 07:59:59 GMT
On Thu, Sep 24, 2015 at 12:32 AM, Jianfeng Jia <>

> 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]

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:

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.

aka Chris Hillery

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message