[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Git commit messages
- From: Wim Jongman <wim.jongman@xxxxxxxxx>
- Date: Wed, 22 Jun 2011 16:44:15 +0200
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wz0UlXNHH76F99gk2zIiu18RYzOOzYfxeFZKqBD2U1u/ayF1WYMXFmToAdcdDPEoqw hHzl6Lk1DVVJFolHibQJzzSFhK38XVoU7mGTyAY6jqnC0FsJf/789AkqdQ4wIrcvXSH8 dUo/WCSGTBIF91dF5BAm/2CD7BfKDDNrJk5bM=
The problem is that you don't exactly know when the change is done and therefore have to type the same message over and over again in multiple commits. Especially if you commit fast and early like you can do in your local repository. This is especially the case if you do a lot of smaller changes: you do a commit for a) with comments, then a commit for b) with comments and the realize that a) needs some more love.
Since we have already typed in the bug, there needs to be some kind of connection between the bug and the connect comment.
Also it would be nice if the commit comment would be included in the bug as a comment.
This is not to delay the implementation of Alex' suggestions but some things that can be discussed or added later.
+1 for the hook.
On Wed, Jun 22, 2011 at 10:52 AM, Markus Alexander Kuppe <email@example.com>
On 06/22/2011 10:48 AM, Alex Blewitt wrote:+1, especially because log messages are available offline and one gets a
> Basically, the convention is to have a single short line of text (less
> than 50 chars) which summarises the change, followed by a blank line,
> and then more text separated by blank lines (if there's more than one
> paragraph). The final section is for Key: Value pairs, which can include
> Signed-off-by and Change-Id as well as custom values, like Bug: 12345.
> Many of the changes in the current ECF log are one-liners, and often
> just reference a bugzilla item. This doesn't help someone who has cloned
> the repository knowing why the changes were made. Consider these two
> changes below (both for the same fix, bug 349078).
> Being able to do 'git log --oneline' and see descriptive changes is a
> lot more useful than being able to see a list of referenced bugs, as
> well as giving someone who has cloned (and may not be connected to the
> internet) the repository.
better idea of what the changes is about on the Jenkins changes page.
If we all agree on it, we might want add a post-receive-hook that checks
the commit message for proper formatting.
ecf-dev mailing list