asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Till Westmann" <>
Subject Re: Merging vs. squashing
Date Thu, 24 Sep 2015 01:01:33 GMT
I’m certainly not an expert on git as I never took the time (or 
needed) 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, …) but it seems that there’s no obvious way to 
achieve all of them.

If that’s indeed the case, we’d have to decide which wish is more 
important and I think that different people will have different opinions 
on this. Since I’m a big fan of readable history (and seeing the 
result of a code review in the master history as opposed to a number of 
intermediate steps), I’m pretty happy with the current state of the 

Given the problem of having a subset of code that could benefit 2 
branches I would try to separate it out, review and merge it to master, 
and to merge 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 

Just my 2c (to have more people chiming in :) )

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 in
> 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 <>
> wrote:
>> On Wed, Sep 23, 2015 at 10:40 AM, Jianfeng Jia 
>> <>
>> wrote:
>>> I hit another similar scenario that squash may make things harder.
>>> Now I’m working the UTF8 encoding task. Some part of work has been 
>>> done
>>> in Taewoo’s branch. But his branch is a bigger change that won’t 
>>> get into
>>> master
>>> soon. I’d like to cherry-pick several commits from his branch and 
>>> then
>>> continue
>>> on my task. Then both of us won’t hit the merging conflict in 
>>> future.
>> That is, I believe, already not true. Cherry-pick and squashed merge 
>> have
>> 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 
>> of
>> its own. I'm not confident this always works, and I've never 
>> experimented
>> 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 
>> understood
>> what works and what doesn't.
>> If we did merges all the time instead of squashes and cherry-picks, 
>> then
>> you would be able to share some of Taewoo's work if you could *merge* 
>> it to
>> your branch. But as you might guess, merging a couple of changes from 
>> the
>> middle of a foreign branch is quite challenging at best.
>> Ceej
>> aka Chris Hillery

View raw message