Re: Patch (apply) vs. Pull

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> 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 ;-).


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html