asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hillery <chill...@hillery.land>
Subject Re: Merging vs. squashing
Date Thu, 24 Sep 2015 06:54:23 GMT
On Wed, Sep 23, 2015 at 6:29 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

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

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.


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

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:

1. Don't rewrite history (which includes squashing or amending commits and
force pushes) on a branch that has been shared to anyone else.

2. Ensure that the commits which are ultimately pushed to master are
sensible, self-contained, well-documented, etc.

There's a small amount of tension between those two rules, but it can be
handled.

Ceej
aka Chris Hillery

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