Epic commit message | Hacker News Reader

Epic commit message

github.com

27 pointsfexl23 comments

I wrote a few similar commit messages - mainly upon merges, but sometimes when commiting small, but important changes too. The result: I was ridiculed and laughed at... I even seem to remember that someone said I was "unfulfilled writer" (believe me, in my language that was much more unpleasant...).

I can't help but think that majority of programmers are just illiterate and they feel threatened when someone actually has the will (as you can probably see from this post my skill isn't all that great either) to write...

Yes, I could have let it slide and simply written "Fixed bug in type_open propagation in parse.c". But I sort of wanted to "punish" myself a little and force myself to write out precisely what I had done wrong in painfully explicit terms. Otherwise, as Brian Griffin said to Peter, I "wouldn't learn anything." ;)

> The result: I was ridiculed and laughed at...

Well fuck these people, I for one am sick and tired of looking for why a code section was changed in ways I don't understand in the log or blame and getting "changed stuff" back. I'd much rather people explained clearly (and verbosely if needed) what the bloody hell they're committing this change for.

Maybe it would help to put design docs somewhere more accessible than buried in the commit log.

It's a little bit cheesy to submit something that you did yourself and describe it as epic (no snark intended).

Source: contact in whois for domain listed in OP's profile is the same as the author of commit in git log.

Related: My favourite pull request ever http://github.com/ericf/yui3-gallery/pull/21

The submitter name is also the github repo's name ...

Yeah, I didn't intend "epic" in the sense of Homeric greatness ... I just meant like a giant tome.

If I had to choose, I'd pick this commit message over "bug fixes" or other similarly uninformative commit messages.

Yep. Especially "bug fixes" which don't actually fix bugs, and "improvements" which touch half the codebase for about 15 different reasons none of which is explained.

Actually, I think this is a really good commit message, period. Sure, you don't want to detail every change to this extent, but important architectural fixes are fine.

(That said, speculating about the future in a medium where you don't necessarily record "well, that didn't work" and cannot go back to add something may not be optimal.)

Would have been hilarious if at the end of all that we see a single line change in the diff and it's just a deletion.

Well, technically, it's not.

It's just a long commit message. Nothing's really 'epic' about it, beyond being rather informative.

ep·ic [ep-ik] adjective

1. noting or pertaining to a long poetic composition, usually centered upon a hero, in which a series of great achievements or events is narrated in elevated style: Homer's Iliad is an epic poem.

2. resembling or suggesting such poetry: an epic novel on the founding of the country.

I was using "epic" with a Jeff Spicoli accent, not in the classical sense. But thanks for the comments!

It would be good if you could categorise your source code comments somehow and have your IDE help manage them.

By default you would browse code with important summary comments visible, but if you're interested in any one area, you could then drill down into much more detailed and text dense comments right within your editor to read about design decisions and the bigger picture in plain English.

Comments could be further categorised into, say, business logic related comments or those related to design patterns, or page flow or test cases or internationalization or whatever, giving you more options to learn about the code and drill into the specific area you care about.

This readily accessible living documentation would be a much better way of learning about code bases in plain English without consulting out-of-date technical specs.

I like what you're hinting at here. In my case, the "IDE" is vim running in a terminal window, with another terminal window to the right where I run git, grep, and tests. Nevertheless, even in this austere environment I could imagine a vim plugin which would let me wrap some sort of bracketed enclosures around piece of text, possibly nested, with the ability to expand and contract with the press of single key. Without even searching, I'll estimate the probability of that already existing as 85%.

Problem is, anyone viewing the code in a normal text display, e.g. on github or plain text editor, would see all the excruciating detail, all the time. But it's an interesting idea.

Perhaps instead of the expand/collapse, I could just use links. Vim users should note that when you're sitting on a word, if you type "gf" it will Go to that File (i.e. open it up right there), and you can use "o" and "i" the way you use "Back" and "Forward" in a browser.

Sorry, I meant you can use "Ctrl-o" and "Ctrl-i" that way.

I think you are going towards Knuth's literate programming. Not a bad approach.

You can probably use folding for this use case. With explicit folding markers "{{{" and "}}}" or other syntax rules it's already possible in all major text editors.

before you go to far into that rabbit hole, turn on whatever fancy blame view you like best. Its probably good enough.

I feel like I've seen this recently on HN

Eh, cannot find it - I guess we just talk a lot about commit messages.

http://www.hnsearch.com/search#request/all&q=commit+mess...

https://www.google.com/search?q=site%3Aycombinator.com+commi...

Maybe it was this one, but I swear it was more recent:

http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-c...

http://geeksta.net/geeklog/exploring-expressions-emotions-gi...

This is called: "programming".

Reply on news.ycombinator.com