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:07 GMT
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