Abhijit Menon-Sen <ams@xxxxxxxxxx> writes: > It was a dark and stormy night. Sam struggled to keep his eyelids open > as he integrated yet another gigantic patch series. Ever the optimist, > he'd pulled in the changes, only to discover several merge conflicts. > But the night was young then, and he'd fixed them all by hand. > > It was only later that he noticed many lousy, one-line commit messages. > Undaunted, he reset his branch and began to cherry-pick patches, giving > them a once-over, writing a comment here, squashing the odd grotesque > hack there, and writing sensible commit messages more often than not. > > But even that was hours ago, and each new but oh-so-familiar conflict > ate into his determination like maggots through decaying meat; and Sam > was beginning to question the wisdom of staying in this fruit business. > His whiskey was running low, and time was running out. > > "If only", thought Sam, "If only cherry-pick would..." That's cute, but I do not think that story is a good example. By "pulled in the changes" do you mean "he merged somebody else's work"? If so, the cherry-pick would be doing rebase of the series manually, and as you already may know, you are not supposed to be rebasing other people's work. And if you are indeed rebasing, that would not be a good example of cherry-pick, either. Do you mean instead "he applied many patches, but there were conflicts and he wiggled them in?" If so, at the resolution time rerere() wouldn't have recorded them in the first place, and more importantly, what you would be cherry-picking won't have conflicts. What the second paragraph describes is what he would do with "git rebase -i" on top of the same base, so there won't be merge conflicts, and even if there were, the use case is again about rebase and not cherry-pick. A better example would be if you have two (or more) maintenance tracks from similarly old vintage and a far more advanced development track, and cherry-picking from that development track to backport a fix down to one of the maintenance track would have conflicts you need to fix. Then you would face the same conflict while propagating the same fix to another maintenance track. But even then, you would most likely cherry-pick the cherry-picked fix from the maintenance track, which would be conflict free, instead of cherry-picking it from the development track. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
