Replies: 1 comment
|
A descriptive commit subject would make the Git history much more useful, and the existing �Usual commit� fallback is a clear place to improve it. I would derive the subject from git diff --name-status and keep it intentionally short: For renames, use the rename status if Git reports one; otherwise treating it as delete plus add is less misleading than calling it edited. The message should be generated from the same commit boundary that FSNotes is about to create, so it cannot describe files that were changed after the snapshot was taken. I would cap the subject at a conventional length and put the full file list in the commit body only if there is a real need. The word-count bonus is probably better left out of the first implementation: it adds noise and is harder to make meaningful for binary, metadata, or formatting-only edits. A preference such as �Use descriptive Git messages� would preserve the current behavior for users who want stable automation-friendly subjects. The implementation should pass file paths as Git arguments rather than interpolating them into a shell command. |
Uh oh!
There was an error while loading. Please reload this page.
Currently, the git history feature will create commits with the message "Usual commit" (set here). It would be nice if the commit contained a short description of the file(s) that changed. I think
"Added/Deleted/Edited File.md"would be sufficient. If multiple files were included in the commit, maybe append a"& n others".(A silly bonus feature would be to include some basic metadata about the edit as part of a longer commit message, like "231 words added", but I only mention it for fun.)
I might take a crack at this if I have spare time, if you think it'd be a good addition :)
All reactions