From: Junio C Hamano Date: Wed, 22 Jun 2005 09:08:54 GMT Subject: Re: Patch (apply) vs. Pull Message-ID: <7vmzpihi6x.fsf@assigned-by-dhcp.cox.net> In-Reply-To: >>>>> "LT" == Linus Torvalds writes: LT> and here the "git-cherry-pick" thing is just a script that basically takes LT> an old commit ID, and tries to re-apply it as a patch (with author data LT> and commit messages, of course) on top of the current head. It would LT> basically be nothing more than a "git-diff-tree $1" followed by tryign to LT> figure out whether it had already been applied or whether it can be LT> applied now. LT> What do you think? What you outlined is essentially what I already do by using jit-rewind, followed by a repeated use of (jit-patch and jit-commit with -m flag). The reason I have not automated the "repeat" part is _not_ because I am lazy, but because typically the rejected things really need manual intervention, not for mechanical (read: merge conflict) reasons, but for semantic reasons, when some patches are accepted while some others are not. Especially if I am not the sole supplier of patches to your tree, my older patches usually need not just rebasing but _rethinking_, so I myself do not find need for automating things further that much from what I already have. Having said that, one automation I would benefit from is to automatically find patches that _have_ been accepted and drop them from my snapshot pool --- that part should be very easy to automate and I have not done so primarily because I _am_ lazy. I could call it git-cherry-drop ;-).