Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <A57D0979-34D4-4F92-926B-C66669C14326@apache.org>
References: 
 <CAHWyyRxv+EpzvybwFQLJR0wd5i=UuVc=HTqLd365UEpXj4LHCQ@mail.gmail.com>
 <CANQf6Dq_Xm2TEjfpDFxTr1psctJ3zWC6fygZRJRBizNZBjWqMQ@mail.gmail.com>
 <CAHWyyRzDWb8Jb8xK19y3VySbZMCPKKgLZcOrZNr8Ny7j1T-eVg@mail.gmail.com>
 <920C6B5B-B0E8-4F3A-AC9E-5DC8FEECC18D@gmail.com>
 <CAHWyyRz-NTu7cfQT0JKEVNiCbDKnh-Xon_VebVOyTwn_vucoQw@mail.gmail.com>
 <CAHWyyRxoHJnQ5SCjS2z=RicO-RXgbRXPPyEdZQe_8U9AsCswxQ@mail.gmail.com>
 <A57D0979-34D4-4F92-926B-C66669C14326@apache.org>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Wed, 23 Sep 2015 18:29:41 -0700
Message-ID: 
 <CAJwFCa2fN=OgXE+wTeFfKzvL_W7xc32be+ne9PDEcN-AOazJzQ@mail.gmail.com>
Subject: Re: Merging vs. squashing
To: dev@asterixdb.incubator.apache.org
Cc: Chris Hillery <chillery@hillery.land>,
 Jianfeng Jia <jianfeng.jia@gmail.com>
Content-Type: multipart/alternative; boundary=001a1140fdea08e0840520742c92

--001a1140fdea08e0840520742c92
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

My experience or knowledge is hardly comprehensive, but merging branches
has most of the benefit of squash commits while retaining history.

Cherry picking (in my experience) works very much as desired. The fact that
a commit exists on two branches doesn't seem to cause any trouble at all at
merge time.  The flexibility is fairly awesome.  I would imagine that there
are counter examples where subsequent changes make the merge complex and I
have no idea what the limits are. All I can say is that in the few years I
have been working with git, I have been astounded at how well the complex
fringes work.

Rebasing interactively is another case.  I routinely use this to make my
local history more sensible. Within reason, it allows me to squash and
re-order my own commits so that there appears to be more order in the
historical record than was in my head at the time I did the work.


On Wed, Sep 23, 2015 at 6:01 PM, Till Westmann <tillw@apache.org> wrote:

> I=E2=80=99m certainly not an expert on git as I never took the time (or n=
eeded) to
> dive deeply into it.
>
> Reading this thread it seems to me that we have a number of reasonable
> wishes what we would like to do (e.g. squash commits to get a readable
> history for the master branch, cherry-pick between branches to avoid
> duplicate work, =E2=80=A6) but it seems that there=E2=80=99s no obvious w=
ay to achieve all
> of them.
>
> If that=E2=80=99s indeed the case, we=E2=80=99d have to decide which wish=
 is more
> important and I think that different people will have different opinions =
on
> this. Since I=E2=80=99m a big fan of readable history (and seeing the res=
ult of a
> code review in the master history as opposed to a number of intermediate
> steps), I=E2=80=99m pretty happy with the current state of the world.
>
> Given the problem of having a subset of code that could benefit 2 branche=
s
> I would try to separate it out, review and merge it to master, and to mer=
ge
> master back into the 2 branches. However, I see that this could be a lot =
of
> work and there could be reasons why is is not feasible.
>
> Just my 2c (to have more people chiming in :) )
> Till
>
> On 23 Sep 2015, at 15:38, Chris Hillery wrote:
>
> P.S. I'd love it if anyone else with opinions or experience would chime i=
n
>> here... I'm pretty sure I don't have all the answers, so I don't want to
>> seem like I'm trying to dictate the discussion.
>>
>> Ceej
>> aka Chris Hillery
>>
>> On Wed, Sep 23, 2015 at 3:38 PM, Chris Hillery <chillery@hillery.land>
>> wrote:
>>
>> On Wed, Sep 23, 2015 at 10:40 AM, Jianfeng Jia <jianfeng.jia@gmail.com>
>>> wrote:
>>>
>>> I hit another similar scenario that squash may make things harder.
>>>>
>>>> Now I=E2=80=99m working the UTF8 encoding task. Some part of work has =
been done
>>>> in Taewoo=E2=80=99s branch. But his branch is a bigger change that won=
=E2=80=99t get
>>>> into
>>>> master
>>>> soon. I=E2=80=99d like to cherry-pick several commits from his branch =
and then
>>>> continue
>>>> on my task. Then both of us won=E2=80=99t hit the merging conflict in =
future.
>>>>
>>>>
>>> That is, I believe, already not true. Cherry-pick and squashed merge ha=
ve
>>> basically the same effect - they create a new commit with no lineage to
>>> the
>>> original. If you cherry-pick from his branch, then even if you merged
>>> yours
>>> to the trunk (rather than squashing), he'd still get conflicts the next
>>> time he updated.
>>>
>>> I will admit I'm not 100% sure I'm correct about this. I've seen some
>>> evidence that git can handle a rebase when the two branches each have a
>>> *single* commit which happens to contain precisely the same diffs, as
>>> would
>>> happen with a cherry-pick that didn't require any conflict resolution o=
f
>>> its own. I'm not confident this always works, and I've never experiment=
ed
>>> to see if it works on a merge rather than a rebase. I wouldn't want to
>>> make
>>> any sweeping process decisions until at least we were sure we understoo=
d
>>> what works and what doesn't.
>>>
>>> If we did merges all the time instead of squashes and cherry-picks, the=
n
>>> you would be able to share some of Taewoo's work if you could *merge* i=
t
>>> to
>>> your branch. But as you might guess, merging a couple of changes from t=
he
>>> middle of a foreign branch is quite challenging at best.
>>>
>>> Ceej
>>> aka Chris Hillery
>>>
>>>

--001a1140fdea08e0840520742c92--