Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: pre-commit changes

Archives

Contributors

Re: pre-commit changes

The idea of the first pre-commit set is to store the automatic changes, so you don't have to review them extensively. The rest of the manual changes to make the linter happy must be on the migration commit, as a third extra commit doesn't make too much sense. You have to review these manual changes, and they can be even provoked by the new code you are introducing for the migration, so better to have all of them in the same migration commit.

Regards.
by Pedro M. Baeza - 08:31 - 5 Dec 2022

Reference

  • pre-commit changes
    Hi,
    quick question about pre-commit changes during migration.

    I'm migrating a module from 14.0 to 16.0. I've noticed that the first pre-commit related commit ("[IMP]: pre-commit stuff") takes care only of part of the changes needed to make pre-commit happy (it is possible due to the --no-verify). The missing part can be significant.
    The following commit ("[MIG]: $MODULE: Migration to 16.0") must include those changes too, plus anything migration related.

    So I was wondering if that defeats the purpose of having pre-commit changes separated in their own commit.  Right now, my approach is to create a second commit, named "[IMP]: more pre-commit stuff", just to make pre-commit happy, and then add another commit with the migration stuff.

    Alternatives I've considered: ignoring the issue and include both migration and the rest of pre-commit changes in one commit ("[MIG]: $MODULE: Migration to 16.0"), or do as I do now but squash the two pre-commit related commits before merge (or equivalently, get rid of the --no-verify in the first place, and manually add all changes to the first commit).

    Thoughts / suggestions?
    by Marco Colombo - 01:46 - 2 Dec 2022

    1 replies 1 replies

    • Re: pre-commit changes
      The idea of the first pre-commit set is to store the automatic changes, so you don't have to review them extensively. The rest of the manual changes to make the linter happy must be on the migration commit, as a third extra commit doesn't make too much sense. You have to review these manual changes, and they can be even provoked by the new code you are introducing for the migration, so better to have all of them in the same migration commit.

      Regards.
      by Pedro M. Baeza - 08:31 - 5 Dec 2022