On Aug 6, 2014, at 8:43 AM, Jakub Narębski <jna...@gmail.com> wrote:
>>> I gave a solution for git using branches and it works just fine. It
>>> retains the simple 3-point merge as well.
> It works for this simple case, but I think it has unfortunate potential
> to go silently wrong.
That just means that you want to have two commands. One for the people that
when the remove a patch, they want it gone. The other for people that when
they remove a patch, they want it to magically reappear. I’m of the former
class of individuals. Now, I would argue that that is the wrong solution of
course. See below for uncherry-pick.
Now, if I needed a solution to the one problem that was mentioned, I would then
request an uncherry-pick command to undo the cherry-pick. The semantics of it
are, the patch is removed from the tree, and when merged, that patch isn’t
removed from the source. See, we then retain the useful property that
everything that should work does, and the system is predictable because it then
does exactly what the user said to do. Conceptually of course, it doesn’t have
anything to do with cherry, if you merge a branch accidentally, and then remove
it, and merge it, I think you still wind up with the work being removed.
Conceptually, it is just an undo a change, cherry, merge, file rename, whatever.
Now, why is this preferable? Because the advanced user gets to explain what
they want to git, and then git does what they want. It also works for
beginning users, it does what they ask it to do. If you are afraid you know
better what command that they really wanted to use instead of the command they
are using, you can prompt them and ask, did you mean this or that? After 20
times being asked, it would get old and then even a new user would just issue
the commands they want. I’m not in favor of that, I’d prefer that the system
just do what they tell it to do.
> Also, it prevents fully removing (commits, not only refs) the branch
> you cherry-picked from. The commit you cherry picked may no longer
> be (or may no longer should be) in the repository.
I’m picking from trunk, when it goes, I go. :-)
> Also, this could be avoided by using feature branches and merging
> instead of committing to one branch and cherry-picking to other
If the problem remains unfixed, at least the documentation should be changed to
say cherry will mess up merge. If you never merge, never a problem. For me, I
would read that, and say, well, trivially, cherry isn’t for me (til they fix
the bug that causes it to mess up merges). I can’t see anything on
http://git-scm.com/docs/git-cherry-pick which says it will mess up merges.--
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