Archives
Contributors
XML errors when upgrading modules, because of fields in unrelated modules
Q: How to Configure GS1 barcodes on Odoo 14 community version
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?
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
Follow-Ups
-
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