On 10/16/05, Kevin Geiss <[EMAIL PROTECTED]> 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
_______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
