Open danbernier opened 2 years ago
I like that idea... I just had the same annoying experience. I wrote a lengthy commit message, commitlint
said NO, and my long commit message was gone.
Unfortunately I think it is not commitlint
, but git
itself, that removes the temporary file with the commit message.
I guess it might be possible to create a copy of the file by simply adding a .bak
to the filename if commitlint
is called with a filename (and not reading the commit message from stdin.).
If commitlint
exits with an OK, it removes the .bak
otherwise it prints the path to the file, so that you can recover the contents for the next attempt.
I wrote a lengthy commit message,
commitlint
said NO, and my long commit message was gone.
It's SO frustrating!
Your .bak
file approach sounds workable. Even if (in the case of a "bad" commit message) you have to manually open the file and copy in its contents, and manually delete the file, it's far preferable to the toilet-flush that you experience this way.
Another idea might be a little more intrusive, but more helpful ... :thinking:
If we decide to fiddle about with git-config, we might save the "bad" message in a file and put its location in config.template
... Thus making git commit
automatically open that file on the next commit
and put it in the editor :grin:
When I write a commit message in my editor, and save and close it, if the message fails
commitlint
, I have to recreate everything I wrote (re-gather reference URLs, re-copy any supporting evidence for the reasoning in the commit, etc), from scratch.It would be great if
commitlint
could keep a record of the last failed commit, so that a freshgit commit
opens it up automatically, and you can make the (usually minor) necessary changes to passcommitlint
.