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
> branches.

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

Reply via email to