losing the commit message when validation fail

[oupala]

This is a great module as it can help to validate commit messages from a team, but there is a pain point: losing the commit message when validation fail.

When trying to commit with a long and multiline commit message, the message is lost if it fails to pass validation (except the first line that is outputted on the console).

Is there a way to avoid losing such messsage, which can become very annoying on a daily usage?

[Garbee]

Can you check .git/logs/incorrect-commit-msgs in the project and see if the whole message is stored there?

If not then we should certainly be able to make it so the whole message is put there.

Either way though, we should have the error message tell people the whole message is there for retrieval.

[oupala]

Yes, the whole message is stored there.

But not only this message: all previous messages and comments are also stored there. It is like a garbage collector of all unused commit message.

But it is not very user-friendly to tell user, "go and search in this hidden file to check if you can find your message among all the lost messages in the garbage". Wouldn't there be a more user-friendly way to tell the user what was his rejected message?

[Garbee]

"go and search in this hidden file to check if you can find your message among all the lost messages in the garbage"

It should always be appended to the file. So instead of that wording we say,

To get the entire commit message that filed, you can check .git/logs/incorrect-commit-msgs and get the last entry in the file.

Now, we should do some delimiter on the messages instead of just a line break. Like # for 80 columns.

We won't print the entire message in the console return since: Is that truly beneficial to be there? Generally, questionable. But there are scenarios where people need minimal output. And generally in CI services you don't care about the entire output, you just care that it failed. Also, it is inaccurate as to what is going on. We are not validating the entire message. So to say, "everything failed" when really only the first line failed can be misleading to users. So returning only the validated data makes the most sense.

As to having it in a hidden folder, what is the alternative here? We pick some arbitrary top level folder or file to put it into? Hoping it doesn't collide with something existing already and then causing that to need to be gitignored. Or do we just use the git folder for what it was meant for? Relevant information to git operations?

[oupala]

I was personally thinking about displaying the faulty message on the console. It is the easier solution when there is an error in interactive mode.

Why are you talking about CI? Does it have something to do with commit message validation?

By the way, is it validate-commit-msg that creates the file .git/logs/incorrect-commit-msgs?

[Garbee]

By the way, is it validate-commit-msg that creates the file .git/logs/incorrect-commit-msgs?

yes

Why are you talking about CI? Does it have something to do with commit message validation?

Typically you'd use CI to validate the messages as well before things are merged to verify they are right. As locally all anyone needs to do is --no-verify when committing to bypass the hooks.

[cmalard]

We could use this idea:

• Save the message to .git/COMMIT_EDITMSG_ERR or something like that
• Remove the file if a commit is valid
• That way we could load it with a prepare-commit-msg hook, that would be cool :beers:

[Garbee]

Ideally, we'd only save the file if the message is invalid. So removing a valid one wouldn't be necessary. If it exists when the hook starts, remove it so it doesn't obstruct things later.

We'd need to still maintain the current file that appends. Just in case anyone has built tooling around that already by chance. In v2 it can be chopped.

SGTM, PRs for the change much welcome.

[hutson]

This package has been deprecated. Please use https://github.com/marionebl/commitlint instead.