Re: Patch (apply) vs. Pull

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 ;-).