{"thread":{"id":"41115","subject":"Detecting redundant commits","startedAt":"2016-01-04T15:59:09Z","lastAt":"2016-01-08T03:14:22Z","messageCount":4,"participants":["greened@obbligato.org","Jeff King","David Greene","David A. Greene"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"275308","messageId":"nngtwmtwd2q.fsf@lnx-dag.us.cray.com","threadId":"41115","inReplyTo":null,"subject":"Detecting redundant commits","fromName":"","fromEmail":"greened@obbligato.org","sentAt":"2016-01-04T15:59:09Z","receivedAt":"2016-01-04T15:59:09Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"I am attempting to teach cherry-pick to handle redundant commits\ngracefully (via a new --skip-redundant-commits option) instead of\naborting. However, I'm struggling a bit with how to check if the\nchanges in a commit will become redundant when appied to the new HEAD.\n\nI found diff_tree_sha1 which seems promising. Am I on the right track?\nIf not, what's the best way to determine whether a commit object is\nredundant with respect to HEAD?\n\n -David\n"},{"id":"275345","messageId":"20160105040026.GB22620@sigill.intra.peff.net","threadId":"41115","inReplyTo":"nngtwmtwd2q.fsf@lnx-dag.us.cray.com","subject":"Re: Detecting redundant commits","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-01-05T04:00:26Z","receivedAt":"2016-01-05T04:00:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 04, 2016 at 09:59:09AM -0600, greened@obbligato.org wrote:\n\n> I am attempting to teach cherry-pick to handle redundant commits\n> gracefully (via a new --skip-redundant-commits option) instead of\n> aborting. However, I'm struggling a bit with how to check if the\n> changes in a commit will become redundant when appied to the new HEAD.\n> \n> I found diff_tree_sha1 which seems promising. Am I on the right track?\n> If not, what's the best way to determine whether a commit object is\n> redundant with respect to HEAD?\n\nDo you mean commits that are in the cherry-pick range but have matching\ncommits already in HEAD? For that, you'd want to use patch-ids.[ch], but\nI think we already do.\n\nOr do you mean commits that, when applied, we find turn out to have\nempty changes (e.g., because we have a set of commits that have\ndifferent patch-ids, but do roughly the same thing)? I don't think you\ncan find that with a straight end-to-end diff. You have try to apply and\nthen look at the result. I think we already catch that case (see\n--allow-empty), though I think the only options are \"preserve\" or\n\"abort\", not \"silently skip\" (and it sounds like the latter is what you\nwould want).\n\nOr am I missing the point completely? :)\n\n-Peff\n"},{"id":"275383","messageId":"49661552-EBD9-4F45-9F31-54B217AE3350@obbligato.org","threadId":"41115","inReplyTo":"20160105040026.GB22620@sigill.intra.peff.net","subject":"Re: Detecting redundant commits","fromName":"David Greene","fromEmail":"greened@obbligato.org","sentAt":"2016-01-05T16:31:04Z","receivedAt":"2016-01-05T16:31:04Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"\n\nOn January 4, 2016 10:00:26 PM CST, Jeff King wrote:\n\n>Or do you mean commits that, when applied, we find turn out to have\n>empty changes (e.g., because we have a set of commits that have\n>different patch-ids, but do roughly the same thing)? I don't think you\n>can find that with a straight end-to-end diff. You have try to apply\n>and\n>then look at the result. I think we already catch that case (see\n>--allow-empty), though I think the only options are \"preserve\" or\n>\"abort\", not \"silently skip\" (and it sounds like the latter is what you\n>would want).\n\nThis. I see where --allow-empty is handled in prepare_to_commit but it is not so easy to skip the commit at that point due to state changes. I was trying to avoid going into commit at all by determining ahead of time whether the commit would become empty. Any ideas?\n\nDavid\n"},{"id":"275521","messageId":"87d1tcyd81.fsf@waller.obbligato.org","threadId":"41115","inReplyTo":"49661552-EBD9-4F45-9F31-54B217AE3350@obbligato.org","subject":"Re: Detecting redundant commits","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2016-01-08T03:14:22Z","receivedAt":"2016-01-08T03:14:22Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"David Greene writes:\n\n> On January 4, 2016 10:00:26 PM CST, Jeff King wrote:\n>\n>>Or do you mean commits that, when applied, we find turn out to have\n>>empty changes (e.g., because we have a set of commits that have\n>>different patch-ids, but do roughly the same thing)? I don't think you\n>>can find that with a straight end-to-end diff. You have try to apply\n>>and then look at the result. I think we already catch that case (see\n>>--allow-empty), though I think the only options are \"preserve\" or\n>>\"abort\", not \"silently skip\" (and it sounds like the latter is what\n>>you would want).\n>\n> This. I see where --allow-empty is handled in prepare_to_commit but\n> it is not so easy to skip the commit at that point due to state\n> changes. I was trying to avoid going into commit at all by\n> determining ahead of time whether the commit would become empty. Any\n> ideas?\n\nI ended up trying index_differs_from(\"HEAD\", 0) and that actually seems\nto work. Unfortunately, it caused a regression and I'm having trouble\nfiguring out why. The code should not even activate without a new\noption specified. If I get it working I'll send a patchset for comment.\nPoint me another direction if I'm way off track. :)\n\n -David\n"}]}