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 <[email protected]> wrote: > On Wed, Sep 23, 2015 at 10:40 AM, Jianfeng Jia <[email protected]> > 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 >
