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
