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 Wed, 23 Sep 2015 22:38:51 GMT
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 <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’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
>

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