asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jianfeng Jia <jianfeng....@gmail.com>
Subject Re: Merging vs. squashing
Date Thu, 24 Sep 2015 18:05:57 GMT
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 <chillery@hillery.land> wrote:
> 
> On Thu, Sep 24, 2015 at 12:32 AM, Jianfeng Jia <jianfeng.jia@gmail.com <mailto:jianfeng.jia@gmail.com>>
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


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