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
<[email protected]> 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
<[email protected]> 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 <[email protected]> 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 <[email protected]> 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
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
