On 10/16/05, Kevin Geiss <address@hidden> wrote:
this method of cherry-picking in git sounds good. but what happens if
you later try to do a normal git-style merge? would in then pick up
the commits you skipped? in otherwords, if you use git-format-patch
once, do you then have to use it forever to get patches from one
branch to the other?
When merging two trees that have diverged, git always does something
that looks like a tla "replay". And for each patch that it is about to
apply, it compares it with the unmerged patches already in the
"destination" branch. It strips whitespace and context from the diff
before the comparison. The relevant code is in git-cherry.
That means that if the patch changed significantly when it was merged
initially, it won't be recognized, and would show up as a conflict. If
the patch merged cleanly, then it''ll all be smooth.
Of course there are dragons there too, if you have a history where you
do and undo the same change a dozen times, and you "cherry pick" one
of the do/undo pairs of commits, any scm lacking mind-reading foo is
going to mess up. OTOH, if you commit history makes sense, you can
relax and enjoy life.
Overall, what I find is that git is great as long as your trees don't
diverge _too_ much, and it tries really hard to converge. When trees
really diverge, you're pretty much solo, but I haven't found any scm
that deals with that gracefully. It's way too complex.
one of the things I like so much about tla is that you can always use
'replay' to just grab the patches you want, however many or few
that is.
I also like tla's replay, but had to abandon it for merges on large
trees. I also bumped into issues where tla's recorded history was
buggy, with broken patchsets (similar to what ablentley was mentioning
not long ago).
cheers,
martin