# Detecting redundant commits 4 messages from 2016-01-04 to 2016-01-08. Participants: greened@obbligato.org, Jeff King, David Greene, David A. Greene. Thread: https://gitlist.dev/t/41115 ## greened@obbligato.org, 2016-01-04 15:59 Subject: Detecting redundant commits Message-ID: URL: https://gitlist.dev/e/nngtwmtwd2q.fsf%40lnx-dag.us.cray.com ``` 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? -David ``` ## Jeff King, 2016-01-05 04:00 Subject: Re: Detecting redundant commits Message-ID: <20160105040026.GB22620@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160105040026.GB22620%40sigill.intra.peff.net In-Reply-To: ``` On Mon, Jan 04, 2016 at 09:59:09AM -0600, greened@obbligato.org 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 ``` ## David Greene, 2016-01-05 16:31 Subject: Re: Detecting redundant commits Message-ID: <49661552-EBD9-4F45-9F31-54B217AE3350@obbligato.org> URL: https://gitlist.dev/e/49661552-EBD9-4F45-9F31-54B217AE3350%40obbligato.org In-Reply-To: <20160105040026.GB22620@sigill.intra.peff.net> ``` On January 4, 2016 10:00:26 PM CST, Jeff King wrote: >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). This. 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? David ``` ## David A. Greene, 2016-01-08 03:14 Subject: Re: Detecting redundant commits Message-ID: <87d1tcyd81.fsf@waller.obbligato.org> URL: https://gitlist.dev/e/87d1tcyd81.fsf%40waller.obbligato.org In-Reply-To: <49661552-EBD9-4F45-9F31-54B217AE3350@obbligato.org> ``` David Greene writes: > On January 4, 2016 10:00:26 PM CST, Jeff King wrote: > >>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). > > This. 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? I ended up trying index_differs_from("HEAD", 0) and that actually seems to work. Unfortunately, it caused a regression and I'm having trouble figuring out why. The code should not even activate without a new option specified. If I get it working I'll send a patchset for comment. Point me another direction if I'm way off track. :) -David ```