[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rap-dev] Git commit messages
|
In the beginning I had similar thoughts and my own problems with the present tense. But after a while I see that it depends on the point of view. Currently you are writing the commit message from your own point of view, but if you look at the changes from the commit itself, then it makes sense that the commit describes what is *does*.
Markus
On Fri, Jun 29, 2012 at 12:40 PM, Tim Buschtöns
<tbuschto@xxxxxxxxxxxxxxxxx> wrote:
Hi.
Agree with the summary-body format
Disagree with the present tense. It feels very unnatural.
For generated message like a merge this still might make some sense, as the commit and merge are really the same thing, i.e. happen at the same time. But when i commit something, i summarize what i DID, not what i'm doing or tell someone to do. Even when you later read the history it feels wrong. Ever read a book written like that? I had to, its very confusing.
Greetings to all
Am 29.06.2012 11:39, schrieb Ralf Sternberg:
Hi all,
I'd like to propose that we agree on a common practise for commit
messages. With git we will never lose any piece of history anymore,
and EGit's blame support makes it easy to track down any line of code
to the commit that has changed it.
A short explanation in a commit helps understanding the changes later
on, and I also think it's a very good practice when you have worked on
a fix for an hour or more, to take a short moment thinking,
summarizing or explaining what you've done and why, before the change
goes into the project's history. Moreover, good commit messages show
that we care for our code base and not just dump stuff into the
repository.
The git commit message format explained in [1] seems to be the
commonly accepted best practice and my suggestion is to adopt this and
add it to our git guide [2]. I quoted the essence below, but check the
article for the reasons. Another good read is the Linux kernel doc
for submitting patches [3]. And there's an Eclipse Bug about commit
messages [4].
--------
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 present tense: "Fix bug" and not "Fixed
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, preceded by a
single space, with blank lines in between, but conventions vary here
- Use a hanging indent
--------
Thoughts? Comments?
Regards, Ralf
[1] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
[2] http://wiki.eclipse.org/RAP/Git
[3] http://www.kernel.org/pub/software/scm/git/docs/v1.7.6.5/SubmittingPatches
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=380550
_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev
Innoopract Informationssysteme GmbH
tbuschto@xxxxxxxxxxxxxxxxx
Tel: +49 721 - 66 47 33 - 0
Fax: +49 721 - 66 47 33 29
