W dniu 2014-08-01 04:43, brian m. carlson pisze:
On Thu, Jul 31, 2014 at 05:58:17PM -0700, Mike Stump wrote:


Cherry picking doesn’t work as well as it should.  I was testing on
git version 1.7.9.5.

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.

In gcc land, I do this sort of thing all the time, and I need a
merging subsystem to actually keep track of things.  I can manage this
will diff and patch and it works flawlessly.  The point of using
something better than diff and patch is for it to be better than diff
and patch.

I’d like for merge to merge in the work that has yet to be merged.
Not that, plus blindly try and apply or reapply cherry picked items.

Note that you should try to avoid cherry-picking, as they do not
leave trace in the graph of revisions.

For example if you are creating a bugfix, instead of putting it
directly on maint, and then cherry-picking to master, it is better
to create a separate feature branch for this fix (based at an early
version), and then merge said branch into maint, then into master.
It is described in blog post by Junio Hamano (which I cannot find now).

You're not the first person to be surprised by the way merge works.
 From the git-merge manpage:

   [This behavior] occurs because only the heads and the merge base are
   considered when performing a merge, not the individual commits.

(That was added after 1.7.9.5.)

If you want the behavior of applying multiple patches in a row, you want
to use git rebase, not git merge.  Since rebase re-applies the patches
of each of your commits on top of another branch, the identical change
won't cause conflicts.

There is also git-imerge, third party tool that is intended to help
merging changes (and make it possible to do it in incremental way).

HTH
--
Jakub Narębski


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