Gabe, I just saw your other e-mail (could you please CC me if you respond to this? My e-mail provider blocks all your e-mails, not even letting reach the spam box...), and although I did not understand the proper sequence of commands done, and I have never had an issue when creating commits after this commit, I will point you to a resource describing how to create a helpful alias in case that pops up frequently to you: https://stackoverflow.com/questions/52975103/how-can-i-recover-the-commit-message-when-the-git-commit-msg-hook-fails
Try to not give up on these checks, since they standardize the codebase, which makes it easier for users to selectively apply modifications to their local gem5. Also, further improvements that depend on the validity of the commit could be made so that the maintainers are automatically assigned as reviewers given the informed tags, or even make these tags be added automatically. Regards, Daniel Em segunda-feira, 10 de fevereiro de 2020 08:57:22 GMT+1, Daniel Carvalho <oda...@yahoo.com.br> escreveu: Hi Gabe, Sorry for the inconvenience, but as Bobby pointed out, the commit message is not discarded, and its backup's location is explicitly stated on a failure. If it is preferred it could also be printed for ease of access, but when I tried this locally it clogged the output, making it harder to identify why the failure happened. Extract of the error message: " Invalid commit header The commit has been canceled, but a copy of it can be found in .git/COMMIT_EDITMSG [...]" Regards, Daniel Em segunda-feira, 10 de fevereiro de 2020 04:56:07 GMT+1, Bobby Bruce <bbr...@ucdavis.edu> escreveu: Gabe, Commit messages are not thrown away but are instead stored in "./.git/COMMIT_EDITMSG" if rejected. Perhaps this should be explicitly stated when a commit message is rejected. As you may already be aware, this is a result of Daniel's (relatively) new git commit message checks: https://gem5.googlesource.com/public/gem5/+/refs/heads/master/util/git-commit-msg.py . It seems the valid arm tag is "arch-arm". You could update your commits with this tag or add submit a change adding "arm" as a valid tag in this file (to lead to further discussion). I personally prefer there being a valid set of tags to stop the constant invention of new tags to describe commits which may, in practise, be duplicates of old tags (though we can expand them as needed). I'm therefore still in support of these checks. It also helps us understand who the maintainers for a particular commits are by cross-referencing with MAINTAINERS.md (fyi: there is no maintainer for the "arm" tag). Kind regards, Bobby -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Sun, Feb 9, 2020 at 7:27 PM Gabe Black <gabebl...@google.com> wrote: > I think until this changes, --no-verify is going to become a permanent > fixture of my commit command line. > > Gabe > > On Sun, Feb 9, 2020 at 7:20 PM Gabe Black <gabebl...@google.com> wrote: > > > Hi folks. I just spent 10 minutes writing up a commit message, only for > it > > to be thrown away because git didn't like the tag I had which I've used > > many times (arm). This is a really bad experience and IMHO not how this > > should be done. > > > > I believe at the time this change was introduced I pointed out how this > > sort of check was a bit heavy handed, and I especially feel that way > after > > it threw away my work. > > > > Gabe > > > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev