On Mon, Jan 04, 2016 at 09:59:09AM -0600, greened@xxxxxxxxxxxxx wrote: > I am attempting to teach cherry-pick to handle redundant commits > gracefully (via a new --skip-redundant-commits option) instead of > aborting. However, I'm struggling a bit with how to check if the > changes in a commit will become redundant when appied to the new HEAD. > > I found diff_tree_sha1 which seems promising. Am I on the right track? > If not, what's the best way to determine whether a commit object is > redundant with respect to HEAD? Do you mean commits that are in the cherry-pick range but have matching commits already in HEAD? For that, you'd want to use patch-ids.[ch], but I think we already do. Or do you mean commits that, when applied, we find turn out to have empty changes (e.g., because we have a set of commits that have different patch-ids, but do roughly the same thing)? I don't think you can find that with a straight end-to-end diff. You have try to apply and then look at the result. I think we already catch that case (see --allow-empty), though I think the only options are "preserve" or "abort", not "silently skip" (and it sounds like the latter is what you would want). Or am I missing the point completely? :) -Peff -- 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