Filter Specific Commits

[m1nkeh]

Not certain if this is a use case for this tool.. but am curious if it's possible to remove specific commits, based on their hash as if they never happened?

A classic example, would be a commit of a secret, which would remain in the history even following removal with a new commit?

Ty.

[newren]

As worded, trying to remove specific commits is more of a job for rebase and doesn't match well with the design of filter-repo. However, if you change your wording to whether you can remove a secret that was committed to some file long ago and make sure it is removed from all versions, then yes that is definitely something that can be done; just use the --replace-text option.

But perhaps let me explain the difference in viewpoint:

rebase uses an entirely different mechanism to work than filter-repo. It operates on diffs between changes, allowing you to e.g. drop or modify the diff, but then runs the risk of conflicts as it attempts to apply diffs from subsequent commits (and for merges it re-does the merge, again risking more conflicts). So, you can make a modification to just one commit, or just drop one commit, and have the changes propagate forward, but you run the risk of every single commit afterwards hitting conflicts.

filter-repo uses fast-export and fast-import which treat every commit not as a diff but as a "use the same versions of most files from the parent commit, but make these five files have these exact contents". So, if you decide to drop a commit or tweak the contents of those new files in that commit, those changes will be reverted by the next commit in the stream that mentions that file because it's not applying a diff but a "make this file have these exact contents". So, filter-repo works well for things like removing a file entirely, but if you want to make any tweaks to any files you have to make the exact same tweak over and over for every single commit that touches that file (thus the need to e.g. use --replace-text). That means rebase is a much better tool if you want to just tweak what kind of changes were included in some old commit and have those changes propagate forward, but the risk of hundreds or thousands of conflicts you need to manually resolve might push you to instead figure out how to programmatically modify each version of the file to be what you want within filter-repo.

[newren]

I'll go ahead and close and assume this answered your questions; let me know if not.

[m1nkeh]

Hmm. again, I've not seen a response notification - looks like i need to prune my GitHub notifications, as they are pretty noisy currently.

Anyway, thanks for the detailed response (as usual). I don't think it answered the question fully.. but it certainly makes me consider the options. Our repository that has these issues is ~3 years old, and has had thousands of commits.. i am exceptionally weary of attempting to rebase this as some of the commits containing issues will be very old (not least of which contain other items that we actually want to retain), and the potential for conflicts is, as far as i understand, enormous.

Your potential solution of removing the offending files.. might actually fit the bill. We can highlight whole files that have things that need to be removed (typically configuration).. completely purge them, and then simply recommit the files back to the repo. A compromise between losing the entire history, which was a proposed solution.

Thank you.