All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Mark Fulton <mfulton26@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Programmatic patches (transform commits)
Date: Thu, 18 Aug 2022 17:48:19 +0200	[thread overview]
Message-ID: <220818.86mtc18sb5.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <CAED_RJPh28o8bFsBEEzAYvp1DXhff2JWiTk3zHh3VbaHZephgg@mail.gmail.com>


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.

  reply	other threads:[~2022-08-18 15:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-18 15:21 Programmatic patches (transform commits) Mark Fulton
2022-08-18 15:48 ` Ævar Arnfjörð Bjarmason [this message]
2022-08-19 10:15 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=220818.86mtc18sb5.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mfulton26@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.