Re: Usefulness of Subject-header of git commit mails
On Fri, Jan 28, 2011 at 11:42, Andreas Hartmetz wrote: On Monday 24 January 2011 00:13:26 Eike Hein wrote: Yep - for the benefit of those who aren't used to the git jargon (sorry for that), in git the convention is to for- mat the commit message like this: single line of about 50 chars, followed optionally by: empty line longer message While deviating from this format is not particularly harm- ful, git and various tools based on git 'rely' on this convention to varying degrees. Semi-OT: What is the empty line good for? Sometimes I just continue writing if the start of a long first sentence turns out to be a good summary. I think it's just to emphasise that the first line is actually a summary (or title or subject or whatever) and not *just* the first line of a multi-line message. The first line should be able to stand on its own and the blank line helps to make that obvious. Parker
Re: Usefulness of Subject-header of git commit mails
On Sunday 23 January 2011, Milian Wolff wrote: 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. Yes, that's right -- and I totally understand why it's useless for other projects. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: Usefulness of Subject-header of git commit mails
Example: [KDevPlatform] fafd165: Don't completely ignore the retrieved top-context For me, this is more useful, so +1 Maybe adding a keyword 'commit' before the short hash like this [KDevPlatform] Commit fafd165: Don't completely ignore the retrieved top-context -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun
Re: Usefulness of Subject-header of git commit mails
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 m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Usefulness of Subject-header of git commit mails
On 1/23/2011 9:30 PM, Milian Wolff wrote: What was broken? Nothing as far as Commitfilter is concerned. Commitfilter actually acts on the X-Commit-Directories headers, not the mail subject. This header was actually somewhat broken in the old mails, it has been fixed now as part of the hooks rewrite that also brought with it the mail subject format change. In total the rewrite fixed numerous bugs, many of which were in the emails (the old implementation wasn't written by the sysadmin team): There were problems with keyword parsing, CCMAIL recipients were not all CC'd to the kde-commits mail but rather individual, new mails were sent, headers with non-Unicode characters in them weren't en- coded properly, authors didn't get CC'd if the hook found something unsafe in the diff, license detection for new files was suboptimal, etc. The rewrite also improved performance by orders of magnitude, especially in the auditing steps, and added new features. For example the mails now mention who pushed a commit. Yet all we hear about is rather aggressive whining about the mail subjects ... yep, being a sysadmin is tons of fun. The sysadmins only told me that they reverted to the old format, because it was the standard for years. They did not give me any arguments in favor of the useless old format, just that they did not want to change anything. I.e.: they didn't have time back when we all moved to git/gitorious back then, now they have the time and want to make it less painful for the people yet to migrate. The change was made on request by several developers who told us they used to rely on being able to tell at a glance which (common root) folder a commit was made too, which is useful in deeply nested repositories or repositories containing more than one application, such as kdepim.git or calligra.git as well as upcoming KDE SC module repositories. I don't know whether you actually lacked the imagination to consider this need or chose to purposely ignore this possibi- lity in order to be able to focus better on saying useless as many times as you felt necessary to get your pet format reinstated, but man, your style sure feels like the latter. FWIW, we already talked about this in the sysadmin the other day (you're in the channel, you can check your backlog for dis- cussion of possible formats around two-three days ago) already and agreed that we want to try a hybrid format that includes both the common root path and the commit subject. We just need to get around to doing it properly (which the old implementa- tion didn't do: it didn't encode nor wrap correctly). The last few days we had some higher-priority tasks to juggle; there's only so many hours in the day. Patches welcome, btw. -- Best regards, Eike Hein
Re: Usefulness of Subject-header of git commit mails
Eike Hein, 23.01.2011: On 1/23/2011 9:30 PM, Milian Wolff wrote: What was broken? Nothing as far as Commitfilter is concerned. Commitfilter actually acts on the X-Commit-Directories headers, not the mail subject. This header was actually somewhat broken in the old mails, it has been fixed now as part of the hooks rewrite that also brought with it the mail subject format change. In total the rewrite fixed numerous bugs, many of which were in the emails (the old implementation wasn't written by the sysadmin team): There were problems with keyword parsing, CCMAIL recipients were not all CC'd to the kde-commits mail but rather individual, new mails were sent, headers with non-Unicode characters in them weren't en- coded properly, authors didn't get CC'd if the hook found something unsafe in the diff, license detection for new files was suboptimal, etc. The rewrite also improved performance by orders of magnitude, especially in the auditing steps, and added new features. For example the mails now mention who pushed a commit. Yet all we hear about is rather aggressive whining about the mail subjects ... yep, being a sysadmin is tons of fun. Sorry Eike, it was not my intention to belittle your (and your fellow's) awesome work on the filter internals. This is (as the subject and contents of this email thread should show) be only about the subject: part of the emails. The other stuff is good (as always), hence nothing I have to whine about :) The sysadmins only told me that they reverted to the old format, because it was the standard for years. They did not give me any arguments in favor of the useless old format, just that they did not want to change anything. I.e.: they didn't have time back when we all moved to git/gitorious back then, now they have the time and want to make it less painful for the people yet to migrate. The change was made on request by several developers who told us they used to rely on being able to tell at a glance which (common root) folder a commit was made too, which is useful in deeply nested repositories or repositories containing more than one application, such as kdepim.git or calligra.git as well as upcoming KDE SC module repositories. I really hate that noone told me this before. I was not kidding when I said what you quoted above. Noone gave me *any* arguments in favor of the old format, except it was like that in SVN times. Hence this whole thread (which, btw, I started since your colleagues told me so). I don't know whether you actually lacked the imagination to consider this need or chose to purposely ignore this possibi- lity in order to be able to focus better on saying useless as many times as you felt necessary to get your pet format reinstated, but man, your style sure feels like the latter. Yes, apparently I do lack the imagination. And it does feel useless (to say it once more), for all projects I work on. With Boudewijn's email I finally understood that this might indeed be useful for some people in some repos. FWIW, we already talked about this in the sysadmin the other day (you're in the channel, you can check your backlog for dis- cussion of possible formats around two-three days ago) already and agreed that we want to try a hybrid format that includes both the common root path and the commit subject. We just need to get around to doing it properly (which the old implementa- tion didn't do: it didn't encode nor wrap correctly). The last few days we had some higher-priority tasks to juggle; there's only so many hours in the day. I was not aware of that, and even though I might be in that channel I don't read it most of the time. If someone told me this before I would not have started this thread at all. Hope you get around to implement this eventually, thanks. Bye -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Usefulness of Subject-header of git commit mails
Eike Hein, 23.01.2011: @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? Would you be OK with this hybrid format that we discussed a few days ago: [repo sans git/branch*] common root path: commit subject * branch only shown if != master. If we could agree on a hybrid, IMHO that'd be a better solution than having different formats in play. It's technically possible to make it configurable, but people who subscribe to multiple repositories with different formats might get irked by it, it might make writing filter rules for some more complex, etc. Yes, it's perfect. Thank you! And as I said - if someone would have ping'ed me on IRC so that I could have read it there, I wouldn't have started this thread at all. bye -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Usefulness of Subject-header of git commit mails
On Sunday 23 January 2011, Eike Hein wrote: @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? Would you be OK with this hybrid format that we discussed a few days ago: [repo sans git/branch*] common root path: commit subject * branch only shown if != master. If we could agree on a hybrid, IMHO that'd be a better solution than having different formats in play. It's technically possible to make it configurable, but people who subscribe to multiple repositories with different formats might get irked by it, it might make writing filter rules for some more complex, etc. Btw. This sounds like a really good format. Though I assume commit subject is still just the first line of the commit message, like it is commonly in git. When you have feature like that, the developers also needs to use that feature, so we need to format the commit messages better now. Hopefully it will come naturally to most developers. `Allan
Re: Usefulness of Subject-header of git commit mails
- Oorspronkelijk bericht - On 1/23/2011 9:30 PM, Milian Wolff wrote: What was broken? Nothing as far as Commitfilter is concerned. Commitfilter actually acts on the X-Commit-Directories headers, not the mail subject. This header was actually somewhat broken in the old mails, it has been fixed now as part of the hooks rewrite that also brought with it the mail subject format change. In total the rewrite fixed numerous bugs, many of which were in the emails (the old implementation wasn't written by the sysadmin team): There were problems with keyword parsing, CCMAIL recipients were not all CC'd to the kde-commits mail but rather individual, new mails were sent, headers with non-Unicode characters in them weren't en- coded properly, authors didn't get CC'd if the hook found something unsafe in the diff, license detection for new files was suboptimal, etc. The rewrite also improved performance by orders of magnitude, especially in the auditing steps, and added new features. For example the mails now mention who pushed a commit. Yet all we hear about is rather aggressive whining about the mail subjects ... yep, being a sysadmin is tons of fun. Hey, look at it differently. If everyone is talking about the subject as the biggest problem, Ben really, really did a great job. I was expecting a hell of a lot more bugs in the brand new code. People complaining about the subject made me smile actually. It is like building a gigantic big house and the owners are complaing about the color of the doorbell. Ill settle for that. Best, toma
