Follow

People who use "git commit -a" give me nightmares. Please don't do that.

@dendy

Review your changes individually. Use "git add -p".

Yes, you may think you know all your changes and you even ran "git diff" five times: this innocent, one-line fuck-up is going to slip in at some point.

@piggo @dendy @fribbledom Yeah, I also do that. `git commit -a` is 'all but not, like, all, ya know?'

@fribbledom @dendy git add -p is one case where I find GUI options better by orders of magnitude. gitg is such a nice, simple interface, or if I’m in Vim already, vim-fugitive does the job too.

@fribbledom I will keep doing that. :D
Then I will "git add *" before immediately remembering that it does not apply to the current directory, but to the whole repository tree.

@bfiedler @fribbledom Well, that would make sense. But for some reason it isn't. * behaves fine otherwise, it's just with git add where it goes wild.

@lanodan @fribbledom ...and in the end you are doing
y
y
y
y
y
and `git commit` anyway
¯\_(ツ)_/¯

@janriemer @lanodan

99% of the time. It's that 1% you're trying to catch.

@fribbledom @janriemer Or you have a repository with the proper atomic commits so reverts and cherry-picks works nicely.
@scruss @janriemer @fribbledom I know that sounds negative but the yes command should be banned imho.
@fribbledom Using `git commit -a` is like using the same password for everything. No sane person does it.

@fabiscafe @fribbledom I guess the complaint is about people who make lots of unrelated changes, then commit them all in one go.

@mansr @fabiscafe

It often leads to that, but that's just one of the side effects of it.

@fribbledom ohhh i thought it was worse than that. i only do really small projects so i don't think this really applies to me

@Strit It’s easier to use just git commit -a. That way, you can write your commit message in an editor and make it longer, more meaningful and give it more thought than simply saying “Bug fixes” or “More improvements,” which is what most people tend to do when writing it from the command line.

At least, that’s my experience. YMMV.

@herzmut @fribbledom

@josemanuel In a world of issue trackers and ticket systems, nobody needs novels wrapped in "meaningful" commit messages for one-line code changes. I also don't need a fullscreen editor to think of a concise message of what has changed. @Strit @fribbledom

@josemanuel @herzmut @fribbledom I often do use full commit messages, but if the fix is a few characters in one line, I do -m.

@fribbledom git add .

git commit -a -m "many changes"

git push --force

@Hanuwu yup, it does if I'm not mistaken. I never use -a, even when starting new projects.

@garritfra mkdir test
❯ cd test
❯ git init
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /home/gxtony/test/.git/
❯ touch README
❯ git commit -a -m "initial commit"
On branch master

Initial commit

Untracked files:
(use "git add <file>..." to include in what will be committed)
README

nothing added to commit but untracked files present (use "git add" to track)

@fribbledom on the one hand i don't do that, because i like to use git status as a pre-flight checklist. but on the other hand, having anything in the working set that's non-ignored and not to be included in the next commit gives _me_ nightmares

@jens @fribbledom i like to squash commits after a PR approval. Especially if it's a blog post, what's the point in having ten extra commits named "fixed typo" . For the git history, you only really need that single commit

@fribbledom Can you point me at the reason for this? I'm not clear on why people do or don't use that option but have seen it recommended.

@Wifi_cable @fribbledom --no-verify nicht vergessen, für diese nervigen git-hooks 🙃

@fribbledom I run git status, git add (if needed) and git diff before git commit -a. I see nothing wrong with that.

@josemanuel

Why make your life that much harder? Developing software is painful enough as it is 😄

@fribbledom It’s the flow I’m used to and it works for me. Of course, others may do things differently.

To me, git add -p intuitively seems more time-consuming, but maybe I’ll try it someday. To be honest, I didn’t know about it until you mentioned it.

@josemanuel @fribbledom Same.

git status
git diff
git -am "A descriptive one-liner; the branch name references the development ticket" – or – git -am "A descriptive summary of the changes; the branch name references the development ticket" -m "A one-liner explaining one part better." -m "A one-liner explaining another part better." -m "Etc."

git add . if new files; git add -i if the circumstances require it (which is as good as never).

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!