Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_C74CA35E-D5B1-4ECC-A6A7-7C44834065E7"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Merging vs. squashing
From: Jianfeng Jia <jianfeng.jia@gmail.com>
In-Reply-To: 
 <CAHWyyRzEhaC0HQC5KGVb+0zN+wpRKuVTjTEiqW-L4BthpL9wAQ@mail.gmail.com>
Date: Thu, 24 Sep 2015 00:42:13 -0700
Cc: Ted Dunning <ted.dunning@gmail.com>,
 dev@asterixdb.incubator.apache.org
Message-Id: <4CC52EAA-ED4D-4A83-BB89-EED4B0DC0E58@gmail.com>
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>
 <CAJwFCa2fN=OgXE+wTeFfKzvL_W7xc32be+ne9PDEcN-AOazJzQ@mail.gmail.com>
 <CAHWyyRzEhaC0HQC5KGVb+0zN+wpRKuVTjTEiqW-L4BthpL9wAQ@mail.gmail.com>
To: chillery@hillery.land

--Apple-Mail=_C74CA35E-D5B1-4ECC-A6A7-7C44834065E7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

To ensure 2, IMO it=E2=80=99s better to enforce that every commit start =
with a jira ticket number. Then at least we can run an eyeball groupby =
on the commit history.

> On Sep 23, 2015, at 11:54 PM, Chris Hillery <chillery@hillery.land> =
wrote:
>=20
> On Wed, Sep 23, 2015 at 6:29 PM, Ted Dunning <ted.dunning@gmail.com =
<mailto:ted.dunning@gmail.com>> wrote:
>=20
> 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.
>=20
> That's good to hear. I have definitely had bad experiences when =
dealing with cherry-picked commits, but I have not been able to pin down =
a specific case where they don't do what you might hope. I'm not sure =
how the git magic works, but it would certainly be compelling if it did =
work.
> =20
> 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.
>=20
> Yes, this is a good strategy that we would definitely want to =
encourage if we were to stop doing the full-squash at commit time. The =
golden rules IMHO are:
>=20
> 1. Don't rewrite history (which includes squashing or amending commits =
and force pushes) on a branch that has been shared to anyone else.
>=20
> 2. Ensure that the commits which are ultimately pushed to master are =
sensible, self-contained, well-documented, etc.
>=20
> There's a small amount of tension between those two rules, but it can =
be handled.
>=20
> Ceej
> aka Chris Hillery


Best,

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


--Apple-Mail=_C74CA35E-D5B1-4ECC-A6A7-7C44834065E7--