Re: cherry picking and merge
On Aug 1, 2014, at 1:02 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Do you mean that "git merge" should be aware of what changes you have
> already cherry-picked?
> It isn't, and that's deliberate
Deliberate bugs are still bugs. In time, users will either wear you down until you fix it, or they will move on to other systems that work better.
> ("git merge" is designed to be simple as possible, though no more simple than that).I sketched a solution that retains a simple git merge…
> 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.
Yeah, my solution doesn’t impinge upon that working nicely. In it, I make cherry use scratch branches to record meta information so that the existing git merge just works. git cherry is free to do the same. Having a git cherry that fully interoperates with git merge, is a feature.
> 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.
I think those two should be the default, but it is easy enough to turn them on that it doesn’t matter much. In my environment, I have both on.