Git your act together | Hacker News Reader

Git your act together

jeffkreeftmeijer.com

77 pointsjkreeftmeijer27 comments

I don't really get people using git commit -m. I never do that. I always use just git commit and write my commit messages in vim that opens up in the same terminal.

First of all, it allows you to easily write extended commit messages (just leave the second line blank and start writing the extended message on the third line). A good idea would be to leave (#more) anchor at the end of the first line, so that others would know there's actually some more info they might want to read.

Then you can always see the files currently being committed while you're in the editor, that's convenient. Last but not least - it helps me take my commit messages seriously.

Occasionally I'm using a terminal which can't open an editor for one reason or another. In those situations I use -m.

If you need more than one line, you can say

    git commit -F -

to specify that the commit message should be read from standard input.

I commit pretty frequently, so unless I'm merging in a large feature I tend to use git -m more often.

That doesn't mean that I don't rebase a bunch of those smaller changes away before pushing them upstream it just means a lot of the changes I commit are small enough that it's easier not to load Vim to write a commit message.

Even better is to use `git commit -v`--it'll have a complete diff that you can review while writing your commit message

Commit messages are important. You should convey what you did.

Commit messages are important. You should make them fun to read.

I actually enjoy witty and clever commit messages. Just the other day one of my coworkers really enjoyed a commit message where I wrote "upgrayedd" instead of "upgrade".

My guess is that the idea to put that in the commit just came to you. So you didn't necessarily go against his advice:

> Don’t try to be clever, witty or funny.

I've worked with someone who did sit around thinking what to put in a commit, and believe me, he didn't commit as often as he should have.

No, it was pretty spontaneous, as the particular individual who typically works with me on that project and I were having a conversation about Idiocracy just hours prior to that.

Until you try to search through your history for everywhere you upgraded something...

I write my fair share of terrible commit messages, too. It always bites me in the ass eventually.

I feel like a better approach for that sort of solution would be to use a hash-tag based (#) tagging system. English has so many tenses and people mis-spell things anyways that basing your search purely off of the text of the commit message is always going to be tricky. Anyways, the point of the commit message is that it be human readable, not machine readable.

Personally, I like clever commit messages. They remind me that the project was written by humans for humans.

It's impossible to know what you'll need in the future, and you can't effectively go back and look for tags, though.

My approach is to add silly things in as fluff, not as the message itself.

    The frobnicator now frobnicates.

becomes

    The frobnicator now frobnicates, omgh4x!!!11

or whatever. Make sure you've got enough _real_ information there, and some light extra whatever is fine.

Then again, sometimes, you really need good commit messages: http://github.com/shoes/shoes/commit/95fed5e6310cb0174ba80b8...

Woah I didn't know about git commit --amend, that's really cool!

A quick note about amend, if you git push before you amend your commit, when you try to push the amended commit, you'll get an error about non-fast-forward references. If you're sure that nobody has grabbed your commit since you've pushed it, you can just git push -f, and it'll replace your original commit with the amended one.

Also for more severe rewriting of the history check out "git rebase -i <base commit>". You'll be shown a list of commits between the base commit and the HEAD in your editor. From here you can rearrange and delete commits, and mark them for editing and squashing.

I use this all the time for cleaning up topic branches before I push them out.

I sometimes use --amend, but it's good to get yourself into the habit of just making a new commit, then squashing it with git rebase -i.

I use magit.el for Emacs which makes this really easy, and if you screw up getting your data back from the reflog is a lot easier than if you just had a bunch of --amend fixups.

git commit --amend is also useful for when you immediately realise that you aren't happy with the commit message (it has a typo in it, or you forgot to mention something), as you can use it without git add -ing anything, just to edit the message.

I don't always commit as often as I should, but ever since reading Ryan Tomayko's "The thing about git"[1], I use git add --patch/-p to solve the problem of overlarge or mixed commits. It allows you to snip out pieces of the changed files to add, rather than adding the entire file at once. (Perhaps everyone already knows this, but I used git for months without knowing it. So maybe I'll save someone else.)

[1] http://tomayko.com/writings/the-thing-about-git

I agree Tomayko's method is very helpful, but I came to the conclusion it's better to just commit as often as possible.

- Multiple changes that affect the same line(s) are very difficult to pick apart.

- It is easier to write a meaningful commit message while the change is fresh in your head; otherwise a lot of time is spent reviewing your changes.

Nice explanation of "git rebase" for combining small commits into one large one.

edit: about funny commit messages :-D

> Newsflash: You’re not funny, you’re being an idiot. :)

Seriously. Just commit one thing at a time. Don’t wait until you go home, don’t fix three really simple bugs before committing, commit every single change separately.

This is important. Nothing fills me with dread like a commit message that says "fixed NullPointerException in renderer (also a few whitespace changes)".

Argh. Don't put a period at the end of a commit message; it's like an email subject line.

Email subject lines are by convention a short explanation of the message. Commit messages, regardless of the SCM, should be the same. The difference with git, and what I inferred from this article, is that commit messages should be verbose. It should be a way for someone to figure out that "bug #33423 has been fixed. Opening files now executes in the proper thread." for a very short message that gets the point across.

If one doesn't have bug tracking software to go to and read about why the commit was done, then it should be much more verbose: "Opening files on a select box executed in the wrong thread. Looks like it erred during startup, where we can't yet fork the process. This patch mitigates the selection box during startup by checking to see if we can fork into our proper thread or not. If we can't, we wait until it becomes available."

There is no reason a commit message cannot be a novel unto itself. And something like that will require a period at the end. If you're trying to limit yourself to a single sentence, or something that can be fit into a tweet, you're only hurting yourself.

See http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa..., http://gist.github.com/539516 etc.

Sounds like a good article. Too bad he had to wrap it in a stupid blog theme that is as narrow as my iPhone display.

Once you discover git rebase -i you will never go back!

So that's what rebase is for! Thanks.

Rebase is a tool to rewrite history. This is just one small part of the things you can do when messing around with your history.

Reply on news.ycombinator.com