Hacker News Reader

Comment by twicetwice | Hacker News Reader

I'm not sure I've _ever_ used the -m flag to write a commit message. Naked `git commit` defaults to vim for me, and that's how I like it. Multiline messages, text turns from yellow to white when you go over 80 characters, summary of changes when you're writing the message, the ability to abort with :q! — I can't say the number of times I've realized I left a bug or forgot to tweak something or stage a change while writing a commit message, and bailed out to fix that before committing — the list of advantages goes on and on. I'll never not write my commit messages in vim, and I encourage everyone to do the same.

View on HN

I use -m often, it's pretty much my default commit method. It doesn't break the flow, I can see the previous commands in the terminal above which is sometimes useful.

Besides it's trivial to change the commit in an editor if you're not happy with it with a simple "git commit --amend". It's even possible to change your mind in the middle of the commit command by adding '-e' as somebody else helpfully pointed out in this comment section.

I mean, I don't think my way is superior to yours, but I don't think it's inferior either. It's just a matter of taste and workflow I suppose. In particular I don't really see why editing text in vim is going to make you more or less likely to realize that you forgot to "tweak something or stage a change". And at any rate as long as you haven't pushed anything it's trivial to rewrite the commit.

I think the biggest difference is once I switched away from `-m`, I tend to write multi-line commit messages. Specifically, I do a title line and a full description in the commit message itself. GitHub will pick this up (if you have a single FF commit) and automatically populate a pull request description with your commit's title and message. As a side-effect, you have a detailed history available for all code patches.

You don't even need to quit editor without saving changes, you can just ^Z it, add new changes, fg the editor back and continue with your commit message.

This is me all the time.

[is writing commit message]

Oh wait… What did I change?

  ^Z
  git diff --cached

Oh yeah.

fg

That workflow seems really slow when dealing with multiple repos/subrepos actively compared to what UI frontends offer.

But it's still more efficient method for single repository project where using UI git client would be the overkill.

You should be using `git commit -v` then; it will include the full diff of your changes, so you can quickly check them while writing your commit message.

Yeah this is what I use, the only issue being extraordinarily large commits may get bogged down some times.

I have no idea why anyone would ever not use this to be honest.

I actually type my commit messages in a new window in the editor (vim).

  :r !git status -v

Type my commit message above the output, and then visually highlight the lines of my commit message and then run

  :'<,'> !git commit -F -

In fact, if I see an issue with the diff, I can update the relevant file and then run:

  :!git add %

and then go back to the window with the status output, delete it and rerun the status -v command.

In fact, if I want to be more fine grained with the changes I stage in git, I can run:

  :r !git diff

to get the output of the unstaged changes, copy the hunk header lines, paste them above the hunk I want to stage, visually highlight the hunk with the header lines, and then run:

  :'<,'> !git apply --cached -

to stage that hunk. I've even done things like using recountdiff to update the hunk header if I decide to removed added lines or restore deleted lines in a hunk. Personally, I think it's easier than using git add -p or reset -p.

Sometimes it's very convenient to start writing your message in the command line, either to delay the "mental context switch" from the command line to vim or when you want to prepend some fixed text to a series of commits.

You can just add -e to the end to either finish writing or checking it in Vim then, which is what I almost always do when I use -m.

> summary of changes when you're writing the message

-v makes this so much better - forget seeing the list of files in the commit; you can see the whole diff! :)

"-m" can be used by automatiom. One of our teams' integrations uses this when automated commits are performed in response to certain actions. E.g., they trigger webpacker builds automatically which are then committed in response to a tag, sprint completion, or other action. (We used to use git hooks which I thought were better, IMHO.)

For anything other than personal projects where messages don't matter much, -m is an anti-patern.

Any good commit message should have at least a paragraph explaining the rationale, functional change and maybe links to design docs or bugs. All the time I come across commit descriptions from decades ago, that are useful because of this.

I personally tend to write pretty short commit messages, I think any important info is better stored either in comments in the code or the module's documentation. Who goes digging into old commit messages to understand what a piece of code does? I know I don't.

Not to say that verbose commit messages are a bad thing, it's always better to have too many details than not enough, but I think very long commit messages might also sometimes hint that either the commit is "too big" and should've been broken down in smaller, atomic changes or, as I said above, that you're really just writing documentation and that may be better suited for an other place.

Commits should definitely be descriptive and accurate, but if you break your changes in small chunks you can generally still do that in one or two sentences in my experience.

I think long commit messages make sense for bugs, because unless it breaks compatibility you're not going to comment the code every time you fix a bug.

In my day job I'm frequently chasing down older code, looking through blame/annotate etc. Commit messages with links to bugs and docs are often the fastest answer to the fundamental questions "Why is this thus? What is the reason for this thusness?"

> Who goes digging into old commit messages to understand what a piece of code does? I know I don't.

A lot of people do. If you've ever used git blame on a file, you can see which commit each line in the file is associated with. You can then run git show <sha1> for that commit and see the message and associated diff. Having that information can help you understand why a change was made and may help you avoid introducing regression type errors.

> Who goes digging into old commit messages to understand what a piece of code does? I know I don't.

If long-term-ism in commit messages isn't something you care about (which is understandable), then consider short-term benefits. When working with my team, I'm able to read some of their recent commits and understand very clearly what's being worked on, without needing to dive into the code or have daily stand-ups which aren't producing any value on their own.

Think of it as an asynchronous way of describing what you're working on, and the broader context.

Git commit messages aren't just messages that you push to whatever central repository; they're also messages for yourself to review while squashing your local history before pushing. I usually make a git commit before testing my proposed change; I don't want to write the full-blown commit message before I know that the tests pass. In that case, -m is very useful to place a marker in the reflog for future reference, even though it won't end up as a message that you share with your collaborators.

The only time I use it is when I'm making a small fix or tweak and will be `rebase -i`ing immediately afterwards. It probably saves me several keystrokes per year.

For that case, commit --fixup and rebase --autosquash might save you even more.

I always use oneliners. Task ID + some short description. Used to use just `-m`, but nowadays I almost exclusively use lazygit to commit.

At work we squash PRs and that's where we can write more details if necessary, or just hope the associated PR with details will be available in the future.

For my personal projects, I don't care that much. When I realize a mistake, there's always amend.

I use -m as a natural filter for line length. If it's unwieldy to fit inside a -m cli flag, it's usually an indicator I can be more concise in my commit message. Obviously, from time to time you'll need to include more information in commit messages; I have sublime set up to be my default editor for these situations.

How do you make naked `git commit` default to emacs?

git config --global core.editor <EDITOR>

It also respects $EDITOR, though that would impact more than just git, of course.

I believe the default is simply to open your default editor so just set $VISUAL (and $EDITOR, read the manual for your shell) in your environment. This has the added benefit (?) of using that editor for commands that open a visual editor such as crontab -e or even visudo (with some caveats of course).

If you want to use a different editor just for git you can set $GIT_EDITOR in your environment.

I'm pretty sour on vim after being forced into it by `git commit` with no introduction or explanation.

Not git's fault, it uses your OS's EDITOR and VISUAL environmental vars (same thing you get when you run, for example, "crontab -e" and other utilities that want a visual editor).

Hm. I don't think I had such a variable prior to the installation of git.

Edit: In fact, still don't. The git editor seems to be configured by some git config rather than environment variables.

The behavior is mostly congruent with other programs, for example less(1) probably also falls back to vi(1) on your system if you press v.

I should clarify, I'm using Windows, which normally doesn't have either of those, except for maybe cygwin or WSL.

TIL, had no idea about that `less` starts an editor on `v`.

Kind announce on Windows https://www.osstuff.com/wp-content/uploads/2019/01/install-g...

Reply on news.ycombinator.com