Mike Stump wrote:
> Cherry picking doesn’t work as well as it should. I was testing on
> git version 126.96.36.199.
> 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
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
* 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,
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