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:42:13 GMT
To ensure 2, IMO it’s 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:
> 
> On Wed, Sep 23, 2015 at 6:29 PM, Ted Dunning <ted.dunning@gmail.com <mailto: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



Best,

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


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