I'm terrible. I'll edit things randomly then make commits before I'm about to do something.
Linus: please write good git commit messages
51–58 of 58 posts
Re: Linus: please write good git commit messages
#52I'm terrible. I'll edit things randomly then make commits before I'm about to do something.
This is one of the great things git makes it easier to do.
Re: Linus: please write good git commit messages
#53I'm terrible. I'll edit things randomly then make commits before I'm about to do something.
git commit -am "Catch-up commit" is a favourite of mine. I could always rebase it at some point…
Re: Linus: please write good git commit messages
#54Earlier quoted context omitted.
So, you've never had a commit like this one? deep/magic: Commit changes even if not dirty. Changesets are somewhat magical these days (obviously!); even if they are not dirtied; they could end up being really, *really* bogus as far as their on-disk status. The reason, as far as I can tell, is that in deep/wizardry, we are being very liberal about our modifications to the on-disk data structures without actually consi…
I would prefer to see that rationale in the comments or some implementation doc or something. In the git history it's eventually going to be troublesome to unearth, unless the change remains intact enough for "git blame" to give you a pointer to that old commit, or your whole team standardizes keywords for more searchable commit messages. And if your team does have a way to find that explanation, you then need some w…
Comments about the change itself, and the rationale behind it, should go in commit messages. Comments about the implementation itself should go in the code. Granted, there is some overlap between the two, in which case, go with code only (since it's part of the commit anyway).
Re: Linus: please write good git commit messages
#55I'm curious about this: please do proper word-wrap and keep columns shorter than about 74 characters or so How come word-wrapping is left as a task for humans here? Is there a technical/stylistic/cultural reason why lines can't be wrapped automatically to any desired width by the log presentation layer?
Because doing so would then require extra complexity to provide a syntax for lines that should not get wrapped, such as code, transcripts, tables, ASCII art... Hard-wrapping paragraphs to a desired length in the original log allows humans to decide which lines should wrap and which ones shouldn't, without a pile of complexity similar to HTML, Markdown, or some other markup language.
>would then require extra complexity to provide a syntax for lines that should not get wrapped,
And what's stopping someone implementing this?
Re: Linus: please write good git commit messages
#56Earlier quoted context omitted.
Is this usually the case that exactly one commit maps to a single issue? I'd rather expect a whole branch to cover one issue (unless it's completely trivial). In this case, repeating the same issue number in every commit message on a branch doesn't seem very useful.
For bugs, I'd expect a single commit to provide the fix; otherwise, the bug report needs splitting into multiple independent bugs. :) Feature requests might require a whole branch, though. But in those cases, each individual commit in the branch would build towards the feature, and should reference the feature request.
From my experience, a bug can be simple to describe and atomic, but still require a significant amount of work to fix. I'm all for linking to bugs and feature requests in commit descriptions, but I wouldn't make it a hard requirement and put on the first line. Your mileage may vary.
Re: Linus: please write good git commit messages
#57Earlier quoted context omitted.
Because doing so would then require extra complexity to provide a syntax for lines that should not get wrapped, such as code, transcripts, tables, ASCII art... Hard-wrapping paragraphs to a desired length in the original log allows humans to decide which lines should wrap and which ones shouldn't, without a pile of complexity similar to HTML, Markdown, or some other markup language.
>would then require extra complexity to provide a syntax for lines that should not get wrapped, And what's stopping someone implementing this?
> And what's stopping someone implementing this?
Most likely, not wanting to inflict such a syntax on git users, when the current approach works just fine.
But nothing stops someone from writing a patch with an off-by-default option for such a syntax, and proposing it for inclusion.
Re: Linus: please write good git commit messages
#58Earlier quoted context omitted.
Couldn't our woes be solved with something as simple as soft-wrap with a tweak: soft-wrap: - to allow the presentation layer to soft-wrap a line, just don't add a newline. - for new paragraphs, just add two newlines as usual - for indent sensitive code, diagrams, etc. add newlines where appropriate, taking care to not exceed 74 columns for any line. Everyone does this already. + tweak: - in the presentation layer, so…
Text that shouldn't wrap can exceed 74 characters. Some examples: log messages, transcripts, large tables. So, no, that wouldn't suffice.
But how are those log messages, transcripts and large tables all that much better off under the current system? If a console is only 80 characters wide, they're still going to either disappear off the right edge or (as with most consoles I can think of) get soft-wrapped by the console anyway.