Open jecisc opened 4 years ago
Having several input fields would need multiple clicks/tabs, confusing the user that does not know how it works, is it mandatory, or not? Should I fill one, both...?
I think it would be better to add some convention, no? Like, if you add an empty line between the first line and the second line, the first one is the summary. Then the convention could be added as placeholder text as an example. What do you think?
Google links to the following template, but maybe too long for our window:
Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug." This convention matches up with commit messages generated
by commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, followed by a
single space, with blank lines in between, but conventions vary here
- Use a hanging indent
Source: https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
Only as a reference (not important), I show how it works in Visual Studio Code. You see a warning at bottom for the current line where the cursor is positioned. I don't like too much this way of showing it. I've checked that you can ignore the warnings and perform the commit.
Usually, git commit messages should be in two parts. One <50 chars to summarize and one with the detail.
Most Git GUI offer two fields. A single line input with a number count (x/50) and an text area.
It would be cool to have that in Iceberg to know if our message will be cut or not.