Usefulness of Subject-header of git commit mails

Milian Wolff mail at milianw.de
Sun Jan 23 22:14:54 GMT 2011


Boudewijn Rempt, 23.01.2011:
> On Sunday 23 January 2011, Milian Wolff wrote:
> > Hey all,
> > 
> > I've brought this discussion to the sysadmins recently and they asked me
> > to ask for feedback here. So there it goes:
> > 
> > Recently, the format of the subject of git commit emails was adapted to
> > use the old SVN format. This sucks in my opinion and I want to have it
> > changed.
> > 
> > First lets explain how the git emails where formatted before:
> > 
> > Before: "gitorious-way"
> > [$repo] $short-sha1: $pretty=online
> > 
> > Example:
> > [KDevPlatform] fafd165: Don't completely ignore the retrieved top-context
> > 
> > This is how they are formatted now (or well - again, apparently this
> > format was used in SVN as well):
> > After: "svn-way"
> > [$repo/$branch] $min-path
> > 
> > where $min-path is the common path of *all* changed files, e.g.:
> > 
> > Example:
> > [kdevelop/4.2] /
> > or
> > [kdevplatform/1.2] documentation
> > 
> > 
> > So why does this suck:
> > 
> > a) the path bears no information whatsoever. Esp. when it turns into '/'
> > and this *does* happen very often. In SVN everything was one repo, hence
> > the path was useful. But in Git everything is split into repos, so the
> > path bears no information.
> > 
> > b) I cannot use quick-seach features of common email applications, like
> > KMail to search by sha/commit msg. I have to use the fullblown search
> > dialog which is much slower to use to achieve such a simple task
> 
> To me, the short sha is useless,

here I can follow you, if I'd be looking for a sha, i'd rather take git log 
directly probably. so indeed, I'd be OK with that getting removed from the 
format.

> and the cut-off bit of the commit message
> doesn't tell me anything useful either. I use the path to filter on which
> part of calligra a commit touches, so it's useful for me.

Hence you imply that this actually works and produces useful stuff in 
calligra. It does not do so for smaller projects where you often touch files 
in the root dir or in two dirs at the same time. I know this will be the case 
for:

massif visualizer
kdev-* (php, php-docs, qmake, python, ...)

In KDevplatform/KDevelop it sometimes has at least some path that says 
*something* like "path/to/plugin" - but what do I care about what files get 
changed? Am I not interested into *what* got changed, i.e. intention of the 
commit? This should (and very often is) contained in the commit message. 

But probably my problem is that I only work on "semi-large" repositories like 
KDevelop/KDevplatform/Kate. There I'm interested in *everything* that goes on. 
In Calligra you have only one big repo for all the apps, correct? Here I 
indeed can understand how the path has still some information value.

@sysadmins: would it be possible to change the format for some repos or is 
this not possible? I.e. leave the decision to the project maintainers?

> And I use the
> sender to order messages when I write a last-week-in-krita.

I only want to change the subject, nothing else.

bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110123/0331addd/attachment.sig>


More information about the kde-core-devel mailing list