On Aug 1, 2014, at 1:02 PM, Jonathan Nieder <jrnie...@gmail.com> wrote:
>
> Do you mean that "git merge" should be aware of what changes you have
> already cherry-picked?
Yes, it amounts to that.
> 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.--
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
