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
world.
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
feasible.
Just my 2c (to have more people chiming in :) )
Till
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 <[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
