On Thu, Aug 18 2022, Mark Fulton wrote: > Is there a way to commit a transform script that programmatically > applies file changes rather than committing the file changes directly? > > e.g. Imagine in a large repository that a contributor wants to replace > certain instances of "abc" with "xyz". A transform script might be > like the following: > > ```sh > #!/bin/sh > > sed -i 's/abc/xyz/g' $(find .) > ``` > > Applying such a "programmatic patch" will potentially edit many files. > Doing a code review on such a change is error prone due to authors > resolving merge conflicts manually, etc. while reviewing the patch in > some circumstances is much easier (especially tools for specifically > this type of file transformations are used to make it easy to parse > code, traverse abstract syntax trees, make edits, etc.). > > Does anything like this exist today? Depending on the implementation I > could see there being cross-platform support challenges but maybe > there is something that already exists to assist with this which I can > learn about. > > As an alternative to making this part of Git I can see tools like > GitHub Actions being used to look for commits of "programmatic patch" > files, pick those up, run them, and commit and push the change but > having a solution for this as part of Git itself would make it > independent of GitHub and more reusable, etc. Yes, e.g. for C (and used by linux.git and this project): https://www.kernel.org/doc/html/v4.14/dev-tools/coccinelle.html Generally speaking I've made such ad-hoc commits in the past, where I've e.g. included the needed script (or one-liner) in the commit message, along with manually adding the diff to the commit message that *isn't* the part changed by the script or one-liner. But I don't think there's any sort of widespread standard for this sort of thing, other than doing that, and the same (sometimes leading to non-atomic commits) of having the manual part of the change applied before or after in a separate commit.
