asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jianfeng Jia <>
Subject Re: Merging vs. squashing
Date Thu, 24 Sep 2015 07:32:22 GMT
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.


> On Sep 24, 2015, at 12:01 AM, Chris Hillery <> wrote:
> On Wed, Sep 23, 2015 at 11:38 PM, Chen Li <> wrote:
>> Just want to echo what Ted said: if the same commit exists in two
>> different branches, then there is no issue when we merge these two
>> branches into the master.  In fact, if branch A has all the commits of
>> branch B, after we merge branch A into the master, git will
>> automatically think branch B is already merged into the master.
> This is true, and one of the key benefits to the merge scenario. However, I
> feel it's important to point out again that a cherry-picked commit is *NOT*
> "the same commit" as far as git is concerned, so if you cherry-pick from A
> to B then A and B do not have the same commits. It may be that git merge
> and/or rebase can detect cherry-picks and handle them better than
> completely exploding. But if you think of them as the "same commit", you're
> giving yourself a bad understanding of what's actually going on, and that
> will eventually bite you.
> (I know you didn't specifically mention cherry-picking, Chen, but in the
> context of Jianfeng's and Ted's earlier messages I think it's still a point
> that bears repeating.)
> Ceej
> aka Chris Hillery


Jianfeng Jia
PhD Candidate of Computer Science
University of California, Irvine

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