Hi Mike,
Mike Stump wrote:
> Cherry picking doesn’t work as well as it should. I was testing on
> git version 1.7.9.5.
>
> Put in a line in a file, call it:
>
> first version
>
> then cherry pick this into your branch. Then update on master and
> transform that into:
>
> second version
>
> then, merge that branch back to master. Death in the form of conflicts.
Do you mean that "git merge" should be aware of what changes you have
already cherry-picked?
It isn't, and that's deliberate ("git merge" is designed to be simple
as possible, though no more simple than that). This way, if on a side
branch someone makes a change that would conflict with "master" and
then backs it out, then the branch can still merge cleanly.
Generally people do one of the following:
* Use a merge-centric workflow. Don't cherry-pick "forward" but
merge instead. (Do use cherry-pick for backports when you forgot
to commit a fix on top of the oldest supported branch that would
need it.) The gitworkflows(7) manpage has more details on how
this works.
* Use a cherry-pick-centric workflow. Never merge. Notice when
you're trying to apply a patch you already applied and skip it.
(Others in the thread have covered this workflow a little.)
Even in those workflows, it's possible to have conflicts due to
genuinely conflicting changes, even with no cherry-pick involved. I
find the '[merge] conflictstyle = diff3' setting (see git-config(1))
and git-rerere(1) to be helpful in making that less painful.
Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
