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

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

> On Sep 24, 2015, at 12:01 AM, Chris Hillery <chillery@hillery.land> wrote:
> 
> On Wed, Sep 23, 2015 at 11:38 PM, Chen Li <chenli@gmail.com> 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



Best,

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


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