I mean this is only a problem if your commit work flow is "git add . && git commit".
A bad habit, in my opinion.
A bad habit, in my opinion.
"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.
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).
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?
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.
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.
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.
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).
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`.
alias ga="clear ; git add -p" is an alias i always seem to keep
Edit: The flag is -N or --intent-to-add
- 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.
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.
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.
It lets you stage individual changes inside files instead of the whole file.
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.
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.
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
fza = "!git ls-files -m -o --exclude-standard | fzf -m --print0 | xargs -0 git add"
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?
(but agreed if you use `-fdx` that doesn't work)