https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38664
--- Comment #14 from Jonathan Druart <[email protected]> --- (In reply to David Cook from comment #10) > I've started to come around to the idea more after participating in the > Mattermost chat, but then I realised there is 1 potential problem with the > pre-commit git hook. > > perltidy doesn't always work. Sometimes it fails and you end up with inline > error messages. For a big dev, this could be a risk. > > I suppose --no-verify could bypass the auto-perltidy and you could always > still provide your own Tidy follow-up if perltidy is failing? > > Just food for thought... Good point, the hook can prevent the commit if the tidy command fails and the files won't be modified (will need a copy before). (In reply to Julian Maurice from comment #11) > > On top of that, add a QA check (if someone forgets to setup the hook) and a > > xt test (if QA+RM forgets to run the QA script), and the code stays tidy, > > forever :) > If it is only caught by the xt test, then it means the main branch is not > tidy (I assume the test is run by Jenkins, not by RM). So perltidy will > still need to be run from time to time ? Not a big deal for me, I prefer > having a code base 100% tidy most of the time than the current state. If we have a pre-commit hook to prevent authors to commit non-tidy code and a QA check to prevent PQA or push of non-tidy code, it should be enough already. The xt test is yet another protection but it should not be needed (but we are humans :D). > Side note: are you considering using https://pre-commit.com/ ? I think it > would be handy when dealing with multiple dev installs, and it would be > easier to update/add new hooks if needed. I did when I introduce the first one, but it seems too much overhead for our simple use cases. > > * provide a script to ease rebases > You got me curious there... Do you have a magic spell or something ? :) The idea (not tested yet and needs to be confirmed/improved/discussed) is to: 0. have a patch set for bug 12345 that has been written before the tidy commit(s) 1. run "the rebase script" a. checkout commit before the tidy bug b. apply patches from 12345 one-by-one c. run the tidy script on each of the commit d. rebase and keep changes from 12345: git checkout --theirs (or git rebase -Xtheirs) 2. Attach the rebased version of the patches The script would then deal with everything for you, apart from the conflicts you would have gotten anyway. We will need to stop the "keep theirs" behaviour after we applied the tidy commits however. (If I have not mixed up ours and theirs once again) (In reply to Katrin Fischer from comment #13) > I am probably not the right person to assess the technical consequences, but > I feel it's important we reach consensus on this as it will affect any > outstanding patches. What I've explained previously is trying to prevent that. The problem will be backports. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
