6 ms·

A simple one is being able to write multiple messages (subject and body), e.g. git commit -m "subject" -m "a longer body" or just running 'git commit' and u

A simple one is being able to write multiple messages (subject and body), e.g. git commit -m "subject" -m "a longer body" or just running 'git commit' and using your text editor (subject first line, body after). I've worked on too many repos with messages like "fixed the thing" where a few more sentences of context would've prevented headaches when trying to debug or change something.

rjmunro 4y ago
I always tell people the `-m` flag of `git commit` is only ever to be used in scripts. Let git open an editor and write your multi-line message there. Look at the comments telling you which files have been changed. Even better than using `git add` and `git commit` is to use `git gui` to add and commit files. The (standard) GUI is not to help beginners, it is to make you a more effective user of git. Note there are other apps you can use with more features, for example I like gitx on MacOS, but there are also terrible apps out there that do try to be easy for beginners, and they should be avoided. The most obvious is github desktop (I haven't tried it for a while - it might have slightly improved, but I still won't go near it)
- pfarrell 4y ago
  Good points. I occasionally use gitk to browse recent commits. A gui definitely has its place. I like using the terminal, so my workflow is to use `git add -p`. That makes me look at each change, in small chunks,as I stage them. As a bonus, it helps me keep commits small, or decide if there’s some logical separation in my changes that would be better expressed in two or more commits.
- cassianoleal 4y ago
  What's `git gui`? $ git gui git: 'gui' is not a git command. See 'git --help'. The most similar commands are ci gc grep init lg80 pull push
  - greggyb 4y ago
    Your package manager seems not to include it. `git gui` is available in the standard Windows installer for git. The package on Ubuntu 20.04 seems to not include the gui. As noted on git website, there are two GUIs that are in-tree -- native components of the project. https://git-scm.com/downloads/guis https://git-scm.com/downloads/guis
    - cassianoleal 4y ago
      Yeah it's packaged separately. I'm using git from Homebrew on macOS.
  - everybodyknows 4y ago
    Alternative: git-log --graph --all --stat
    - rjmunro 4y ago
      That's more like gitk, not git gui. On ubuntu it's a separate install from the main git, https://launchpad.net/ubuntu/bionic/+package/git-gui https://launchpad.net/ubuntu/bionic/+package/git-gui Try `apt install git-gui`, or similar.
  - WorldMaker 4y ago
    You may be able to get to it from `gitk` (it's under File > Start Git Gui). I've seen distributions that don't include the `git-gui` shortcut in PATH but do add `gitk` to somewhere in PATH.
    - cassianoleal 4y ago
      Thanks for the tip. I was mostly curious about it as I had never used or heard of it. I have looked into gitk in the past, and also other GUIs but I find git easier to use via the CLI.
- chrismorgan 4y ago
  > Look at the comments telling you which files have been changed. And you can make this even better by adding the diff that’s being committed with verbose mode (see `git commit --help`), so that you can scroll down and easily see exactly what’s going into the commit: git commit --verbose You can make it permanent so: git config --global commit.verbose 1 I also recommend setting commit.cleanup = scissors as a related thing.
  - bityard 4y ago
    Thanks for this tip. One of the things I always did in larger commits was compose the commit message in a separate text editor while reviewing the diff in my terminal. This puts the diff right where I can see it, although time will tell if I enjoy scrolling up and down to switch between reading the diff and editing the commit message.
    - chrismorgan 4y ago
      See if your editor supports a split view; in Vim, for example, you have :split or :vsplit.
- atq2119 4y ago
  In addition to 'git gui' I would also recommend 'tig'. It allows you to stage individual lines and hunks like 'git gui' but also has a history view. With a little bit of creative key binding, this makes creating --squash commits a breeze. (It also has mouse support which needs to be enabled manually in the config.)
afarviral 4y ago
I'd love to know how to do this in VSCode. Its infuriating that it yells at you for exeeding a 50 character limit.
- pc86 4y ago
  The terminal in VSCode. Over the past 6 months or so I've been forcing myself to move as much of my workflow into the terminal as possible and I've found things have been continually getting easier and easier. A lot of arbitrary restrictions based around half-baked UIs get removed when there's no more half-baked UI.
- pie_flavor 4y ago
  Hit enter. Line #2 starts the body.
- Vendan 4y ago
  do `export EDITOR="code -w"` `git commit` will then open up the commit message as a temp file in vscode, you can write your message then save and close (cmd-s, cmd-w on mac, probably ctrl-s ctrl-w on windows and linux?) and git commit will continue on. `code -w <file>` is telling vscode "open this file for editing and don't return until the user closes it"
- WorldMaker 4y ago
  The 50 character limit warning is just for the "top line" of a commit, the "commit subject line". It's general good advice to keep things like `git log --oneline` readable for people using fixed width command line terminals to view commit logs. VS Code expands the box as you add newlines to allow you type a longer body below the "subject line". The lines in the body also give you suggested warnings to stick to 72 characters or below, which also comes from general good advice to keep things readable in fixed width command line terminals for things like `git log` and `git show <commithash>`. In some ways those warnings/general advice follow things like writing a plaintext email (or usenet posts or…) in pre-GUI days. You don't have to follow those warnings' advice. You may not care how your commits look in fixed width command line terminals. Some GUI tools format commit messages poorly if you actually format it like an ancient email, and you can just write paragraphs and let the people with fixed width command line terminals use a pager tool that can better reflow the text for them. The point is the advice comes from a good place, and there are git repos that are sticklers for plaintext commit formatting requirements which is why VS Code shows that advice. But you don't have to follow it.

rjmunro 4y ago

I always tell people the `-m` flag of `git commit` is only ever to be used in scripts. Let git open an editor and write your multi-line message there. Look at the comments telling you which files have been changed. Even better than using `git add` and `git commit` is to use `git gui` to add and commit files. The (standard) GUI is not to help beginners, it is to make you a more effective user of git. Note there are other apps you can use with more features, for example I like gitx on MacOS, but there are also terrible apps out there that do try to be easy for beginners, and they should be avoided. The most obvious is github desktop (I haven't tried it for a while - it might have slightly improved, but I still won't go near it)

pfarrell 4y ago
Good points. I occasionally use gitk to browse recent commits. A gui definitely has its place. I like using the terminal, so my workflow is to use `git add -p`. That makes me look at each change, in small chunks,as I stage them. As a bonus, it helps me keep commits small, or decide if there’s some logical separation in my changes that would be better expressed in two or more commits.
cassianoleal 4y ago
What's `git gui`? $ git gui git: 'gui' is not a git command. See 'git --help'. The most similar commands are ci gc grep init lg80 pull push
- greggyb 4y ago
  Your package manager seems not to include it. `git gui` is available in the standard Windows installer for git. The package on Ubuntu 20.04 seems to not include the gui. As noted on git website, there are two GUIs that are in-tree -- native components of the project. https://git-scm.com/downloads/guis https://git-scm.com/downloads/guis
  - cassianoleal 4y ago
    Yeah it's packaged separately. I'm using git from Homebrew on macOS.
- everybodyknows 4y ago
  Alternative: git-log --graph --all --stat
  - rjmunro 4y ago
    That's more like gitk, not git gui. On ubuntu it's a separate install from the main git, https://launchpad.net/ubuntu/bionic/+package/git-gui https://launchpad.net/ubuntu/bionic/+package/git-gui Try `apt install git-gui`, or similar.
- WorldMaker 4y ago
  You may be able to get to it from `gitk` (it's under File > Start Git Gui). I've seen distributions that don't include the `git-gui` shortcut in PATH but do add `gitk` to somewhere in PATH.
  - cassianoleal 4y ago
    Thanks for the tip. I was mostly curious about it as I had never used or heard of it. I have looked into gitk in the past, and also other GUIs but I find git easier to use via the CLI.
chrismorgan 4y ago
> Look at the comments telling you which files have been changed. And you can make this even better by adding the diff that’s being committed with verbose mode (see `git commit --help`), so that you can scroll down and easily see exactly what’s going into the commit: git commit --verbose You can make it permanent so: git config --global commit.verbose 1 I also recommend setting commit.cleanup = scissors as a related thing.
- bityard 4y ago
  Thanks for this tip. One of the things I always did in larger commits was compose the commit message in a separate text editor while reviewing the diff in my terminal. This puts the diff right where I can see it, although time will tell if I enjoy scrolling up and down to switch between reading the diff and editing the commit message.
  - chrismorgan 4y ago
    See if your editor supports a split view; in Vim, for example, you have :split or :vsplit.
atq2119 4y ago
In addition to 'git gui' I would also recommend 'tig'. It allows you to stage individual lines and hunks like 'git gui' but also has a history view. With a little bit of creative key binding, this makes creating --squash commits a breeze. (It also has mouse support which needs to be enabled manually in the config.)

afarviral 4y ago

I'd love to know how to do this in VSCode. Its infuriating that it yells at you for exeeding a 50 character limit.

pc86 4y ago
The terminal in VSCode. Over the past 6 months or so I've been forcing myself to move as much of my workflow into the terminal as possible and I've found things have been continually getting easier and easier. A lot of arbitrary restrictions based around half-baked UIs get removed when there's no more half-baked UI.
pie_flavor 4y ago
Hit enter. Line #2 starts the body.
Vendan 4y ago
do `export EDITOR="code -w"` `git commit` will then open up the commit message as a temp file in vscode, you can write your message then save and close (cmd-s, cmd-w on mac, probably ctrl-s ctrl-w on windows and linux?) and git commit will continue on. `code -w <file>` is telling vscode "open this file for editing and don't return until the user closes it"
WorldMaker 4y ago
The 50 character limit warning is just for the "top line" of a commit, the "commit subject line". It's general good advice to keep things like `git log --oneline` readable for people using fixed width command line terminals to view commit logs. VS Code expands the box as you add newlines to allow you type a longer body below the "subject line". The lines in the body also give you suggested warnings to stick to 72 characters or below, which also comes from general good advice to keep things readable in fixed width command line terminals for things like `git log` and `git show <commithash>`. In some ways those warnings/general advice follow things like writing a plaintext email (or usenet posts or…) in pre-GUI days. You don't have to follow those warnings' advice. You may not care how your commits look in fixed width command line terminals. Some GUI tools format commit messages poorly if you actually format it like an ancient email, and you can just write paragraphs and let the people with fixed width command line terminals use a pager tool that can better reflow the text for them. The point is the advice comes from a good place, and there are git repos that are sticklers for plaintext commit formatting requirements which is why VS Code shows that advice. But you don't have to follow it.