Disagree. How is that a bad habit? My workflow is "git status" to check what I've changed, "git add --all" and then "git commit".

"git status" needs to be clean. I don't want to see any untracked temporary files. If it's untracked either it needs to be ignored or it's a new source file to add to the index.

Keeping untracked files lying around not gitignored is a recipe for one day committing one by mistake, or conversely, that some of them are source files you've forgot to commit. I've seen both things from junior developers, that do not know of .gitignore.

>"git status" needs to be clean. I don't want to see any untracked temporary files.

Why do you not want to see any untracked files? What harm does it cause? What is the problem that you are trying to solve?

> If it's untracked either it needs to be ignored or it's a new source file to add to the index.

Or it is a file that stores your notes or experiments that don't necessarily belong in a branch, do not want to include in your next commit, but you also don't want to be invisible to ".gitignore" aware tools - and increasingly many modern tools are (vscode, ripgrep, emacs's projectile to name a few).

>Keeping untracked files lying around not gitignored is a recipe for one day committing one by mistake, or conversely, that some of them are source files you've forgot to commit.

Neither of those are a factor if you consciously check what you are committing using "git status" and "git diff --cached".

This is the habit you want to inculcate in your junior developers, that they should consciously think about the commit they are sending for code review, not that they should meticulously manage and be completely dependent on .gitignore (and i presume you also mean .git/info/exclude - because of course they would also have local files that they don't want to commit but are not worthy of being put into the repo's .gitignore).

There is value in "making a decision" for each untracked file, of whether to explicitly add it or ignore it. This combines well with things like a PS1 that indicates if you have any unclean state (including both changes and untracked files). Every single time I find myself with an untracked file, I can either add it because I want it tracked, put it in .gitignore if it's something generated that I want my whole team to ignore, or put it in .git/info/exclude if it's something I've done locally that doesn't fit either of the above.

>There is value in "making a decision" for each untracked file, of whether to explicitly add it or ignore it.

I would argue that you should decide between explicitly adding it or ignoring it, or deliberately doing neither.

>This combines well with things like a PS1 that indicates if you have any unclean state (including both changes and untracked files).

If you intend to keep untracked files in your directory, choose a PS1 that does not bother you about untracked files.

You are losing important information from git status when you exclude untracked files that you are actually working on and not just some random junk your ide generated. What if you look at the git status and conclude that there are no unchanged files worth tracking and then with that false sense of safety decide to run 'git clean -fdx'? You would lose those files permanently!

I honestly don't understand why the presence of untracked files in your git status is such a bother to you!? Like how exactly does it hurt?

Cognitive clutter. Some people don’t care but it distracts me to no end. I want `git status` to tell me things that matter.

I certainly don’t want a meaningful code change sandwiched between an open editor swap file and some for-my-eyes-only temporary design scratch pad.

> then with that false sense of safety decide to run 'git clean -fdx'? You would lose those files permanently!

Correct, and that’s one of the reasons why the `-f` switch might be a poor fit. I use `-i` instead.

>I certainly don’t want a meaningful code change sandwiched between an open editor swap file

We are specifically not talking about the junk files created by editors and ides here.

We are talking about things like notes and exploratory code that you have written that you have no intention of committing, at least not right away. Why wouldn't you want to see them in your `git status`?

Another problem with putting such files in gitignore is that those files will become invisible to an increasingly large number of tools (vscode, ag aka silversearcher, ripgrep, emacs's projectile to name a few) that rely on gitignore to filter out unwanted files. So now, as far as these tools are concerned you have put your notes and experiments in the same category of files as editor junk and build artifacts. You either search them all or none at all.

> Why wouldn't you want to see them in your `git status`?

I tend to function poorly around cognitive clutter. It distracts me from the important stuff: the files I’ve decided to put under version control. YMMV.

> will become invisible to an increasingly large number of tools (vscode, ag aka silversearcher, ripgrep, emacs's projectile to name a few)

That doesn’t really seem to be the case with VS Code. Ignored files appear grey but they’re still showing up for me.

>Ignored files appear grey but they’re still showing up for me.

They show up greyed out in the explorer yes, but they won't appear when you navigate with "Go to File" (ctrl+p) and they won't be searched through with "Search" (ctrl+shift+f).

Good point!

This is what I do. Is there a "better" habit?

Try `git add --patch` (or just `-p`). git will go through each change and you can decide if you want to stage it. You can even stage individual changes in a file.

This doesn't cover new files though. For those you can use `git add $filename` or even globs with `git add src/some/dir/*.$extension`.

For new files I use `git add -N` (if memory serves right; I am on mobile) to mark them as "I want this file to be included in `git add -p`"

Edit: The flag is -N or --intent-to-add

You can use `git add -i` to pick files to add interactivelly

This is cool, wasn't aware of it.

I use `git add -p` regularly, and it's one of my major pet peeves that it doesn't include new files. I constantly forget to include those in commits because of that.

came here to say this, git add -p is such a brilliant thing.

alias ga="clear ; git add -p" is an alias i always seem to keep

What type of workflow do you use where you regularly want to commit only some of your changes to a file? I honestly don't think I've ever had that need.

It's an extremely common and useful way to use git if you are making small and directed commits. This allows you to write code for some feature which includes multiple changes to a file, then make a few different commits with useful commit messages which describe and explain the changes - e.g. the first to include the definition of a new function and why/how it works, a second to modify some constant variable, and a final one to add calls to your new function at some callsite.

Working in this way creates more commits, but with them comes the context of the change, written in the commit message body as prose. This sadly isn't a common way to use git at lots of companies unfortunately, but it unlocks a ton of gits power and makes the commit log and tools like `git blame` and `git bisect` actually useful.

If you're making single commits that affect lots of files and descriptions like "Updated foo.py", you're missing out on a lot of the benefits that git provides.

While some might be more rigorous about working on a commit at a time, a couple other helpful bits are:

- Cleaning up print() calls and similar debug - It's a first-pass review of your own changes; re-read docstrings/comments, and easily go right back to them and update them etc. The diff view is different from the coding view and you gain insights, etc.

This might apply moreso to my often script-oriented coding that does 20 new things, rather than e.g. unit-test backed "formal" coding that does a few specific things.

My own workflow isn't quite at the "commit often" level of frequency, but instead I'm simultaneously crafting several related but separately-reviewable commits in one branch for one PR.

`git add -u` for changes to existing files, and manually `git add` new files. `git diff --staged` to review what's staged. You can use `git gui` to do all this using a GUI.

Yes, the moment you construct a commit by 'git add' is the moment you review the changes you made. Very often you will find results or configuration files get added without you realising it; or you added a breakpoint() that you shouldn't commit, etc. Second, for meaningful commit messages, the commit should include changes that are related to each other. In summary `git add --all` or `git add .` should be used only after a careful inspection of `git status` or `git diff` showed you indeed need all changes, and that they belong to the same commit message.

Logical changes aren't necessarily partitioned by file. Very often I find they are not. I might make a feature or fix or cleanup that is say 10 related changes that each affect some subset of say half a dozen files, often even the same code multiple times.

Adding individual files can help partition out some changes, but it's very rare for me, it's much more often I have to go back and manually shuffle sub-file changes around if I didn't get the splits right the first time.

You could use `git add -p`

It lets you stage individual changes inside files instead of the whole file.

Right, I can do those things and sometimes do. Similarly to per-file I generally don't need to because I try to write and commit a logical change at a time.

I have no problem with people who do it some other way, it just seems odd to hear people proclaim a particular way to work with git is wrong, because it does not match how they work. Not sure if it's because they can't imagine any other way of working, or they just think all other ways are also wrong.

Just use git-gui

Even if you don't want to go the whole "git add -p" route, at the very least:

1. Use "git add <filename>" manually for the files you want to add.

2. Do a "git status" and "git diff --cached" to review what you are about to commit before committing it.

I quite like my habit of adding stuff with `git add --patch` since it forces me to re-read stuff before I commit it. Graphical git clients like Fork or Sourcetree also allow to commit stuff in chunks.

Agreed. This is the only way I ever add anything.

What's also useful is to set "commit.verbose" to true; then you get the diff in your editor when composing the commit message. This allows reviewing the diff and you can abort the commit if it's wrong.

To add to sibling comments which describe various uses of `git add`, I'll also recommend `git commit -a`, which adds all changes from tracked files (but unlike `git add .`, not untracked files) before committing.

I use fzf in multi-select mode

    fza = "!git ls-files -m -o --exclude-standard | fzf -m --print0 | xargs -0 git add"

That lets you interactively choose which files to stage.

I've started using lazygit and/or tig, these present a UI in the terminal and easily allow staging files. Lazygit also easily allows staging parts of a file; not quite sure about tig.

git gui

Add hunks, write the message, add more hunks, write more message. Once you are happy commit it, close the window. Don't try to use the CLI only because you are a power user who only uses the command line.

If you really can't use the gui (like your on a remote SSH session or something), the non-gui equivalent is git add -p, write your message in another editor, then git commit -F message.txt

Magit also makes this easy. One of the main features of magit, I think.

It also keeps them from polluting git status

How is the git status "polluted" by reporting untracked files that you don't intend to commit?

If anything, I would say that such tricks make git status lie to you. What if you look at the git status and conclude that there are no unchanged files worth tracking and then with that false sense of safety decide to run 'git clean -fdx'? Sounds like an easy way to lose work.

Why is presence of untracked files in git status bothersome to anyone, especially when that is exactly what they are intentionally doing?

if you do a `git clean -f`, untracked files get deleted. Ignoring files that should stick around helps ensure that command can be used nicely. I've never used `git clean -fdx`, not sure why you would use the `-x` flag at all.

(but agreed if you use `-fdx` that doesn't work)