And obviously, it also "ignores" the .gitignore itself because it matches "*", while still taking it into account, which is what I need.
And obviously, it also "ignores" the .gitignore itself because it matches "*", while still taking it into account, which is what I need.
$ git config --global core.excludesfile ~/.gitignore
Then you can put all the standard things you want to ignore into it: $ cat ~/.gitignore
.DS_Store
./drafts/
*.swp
And it will apply to all git commands on your computer.We spent a good part of a day rebuilding a repo after a junior dev. left, when we found out they'd misused global gitignore and hadn't commited several important files due to an ignore they had set for a seperate project.
Lessons learnt. Ensure new devs don't use it, and code review on another machine than theirs...
Shocking I know /s.
But not everyone on here is part of a 20 man SV tech startup making the next social media for beagles and deploying 50 times a day...
lmao!
A broken code should not be able to make it to production, there should be several steps to prevent that, including: Peer review, CI, QA, a staging environment, manual testing, etc.
Always assume that developers can screw up in trivial ways, and build your delivery system such that trivial screw ups will be caught early, rather then dictate how your devs setup their work stations.
Also don’t code review the code it self, review the diff.
A significant percentage of the most critical problems I detect during reviews is in the parts that have not been changed, invisible in the diff. A good diff is necessary, but not sufficient.
Wrote more details about how I do this here: https://alexplescan.com/posts/2022/04/17/the-x-files/
I'd just been bumping into this problem, but hadn't conceptualized such an elegant solution, so kept fumbling around, adding/moving things, futzing around with git way more than I wanted to.
Thank you!
If another developer has added a 'source.file' and you pulled it in, your global gitignore would not be triggered, since the file is already tracked in the repo.
Tangentially, to prevent scenarios where generated code becomes out of sync, in your CI you should always re-run generators and check that `git status` shows no entries (and fail the build if it does).
I didn’t downvote you, and I don’t understand your sarcasm toward me when I’m trying to explain the practical answer to the question you asked. This isn’t just a few lines on a large project, and it’s not even about the extra lines at all. The issue is that personal preferences don’t belong in a shared file, and their presence can cause real and actual problems in a large project, problems I’ve witnessed and experienced first hand. One single bad line in .gitignore can cause trouble for everyone on the team when they need to checkout different branches. If you have 50 or 100 people adding their own ignores, they can and do easily conflict with each other. The shared .gitignore just isn’t the spot to list your personal folders, which is why git designed other places for you to put those.
* IDE/Editor (for example, add `.vscode` to your global gitignore if you use VSCode, add `.idea` if you use IntelliJ family, NOT add `.editorconfig` because that's intended to be cross environment)
* OS level spam (`.DS_Store`, etc.)
* Any file generated by a tool you use locally
Also a pro tip, I have this alias in my global git config:
why-ignore = check-ignore -v --no-index
So I can use `git why-ignore path/to/file` to show why a file is ignored (e.g. it shows which line in which gitignore file excluded it). .envrc # direnv, where I store my local project configuration
.vscode
and when I remember to use them: *.gitlocal
*.gitlocal*
To store files and directories I don't ever want to push, mostly for scratch files and logsAnyway, stuff in .gitignore can still be added to the index if you so wish.
Editors and IDEs are crafting tools. Crafting tools are meant to be mastered by workers (here: developers), not to enforce some team/company policy.
There are tools that already exists to enforce team policies like formatters, linters and so on. These tools generally integrate well with your editor of choice and can also be integrated on your CI pipelines.
What do you need to share btw? There's editorconfig, prettier, git hooks, etc. for style. direnv for configuration (I usually commit a .envrc.example file). I can't think of anything else.
For example specifying custom java faces components directory that will be used once the application is packaged into a war file, so IntelliJ knows they are accessible from JSP html files, and will autocomplete and show you what attributes you can modify on the component.
Another spot of problems was the plugin specific files (that inevitably also got checked in). When someone checked them in again and you hadn't updated this particular plugin, the newer file format caused it to crash. Not a problem for the dev who checked it in, but a problem for everyone else.
I am a strong proponent now of not checking in files that are IDE specific unless the developers are all completely aware of what files do what and the associated churn that a file may have through normal use.
Having maven and editorconfig instruct IntelliJ on how to make a workspace consistent results in less config file churn and avoids people accidentally checking in the compiler settings on their computer, database configurations (with passwords), run configurations (with passwords) and similar.
Checking in IDE files can be done, just that the developers all need to be diligent in checking what they check in. I've rarely been in an environment where that is the case for everyone.
I have a few team who does commit their .vscode folder, they use it to set up their environment the same way (usually when a project differs from another).
IntelliJ recommends not checking in a few types of files that are specific to the individual: https://intellij-support.jetbrains.com/hc/en-us/articles/206...
A .vscode/extensions.json file just specifies extension 'recommendations', and I find, really accelerates developers becoming productive in a project.
If I want to encourage small, one-off contributions, I want to support a user workflow that's as close as possible to:
git clone <project>
git switch -t <branch>
code <project>
npm ci | dotnet restore | terraform init | go get | <whatever>
<change and test>
git add <changes>
git commit
git push
With the right set of extension recommendations and default code settings, a VS code user can automatically be prompted to get the right test executors, linters, prettifiers, and so on so that they get instant feedback on their changes.It doesn't even matter if many users who work on the codebase day to day actually use emacs or a highly customized IntelliJ setup or whatever - the vscode settings specifically enable the driveby coder to get a working environment fast, and that helps enable the power users to not be bothered by feature requests that could be pull requests.
At my last job we had a mono-repo with the .idea directory (for IntelliJ) commited. For Java projects IntelliJ needs to sometimes be directed to understand what folders are “resources” to allow better autocompletion and highlighting. For example specifying custom java faces components directory that will be used once the application is packaged into a war file, so IntelliJ knows they are accessible from JSP html files, and will autocomplete and show you what attributes you can modify on the component.
It’s definitely not a never situation. You can commit only certain files from the configuration (project settings not editor preferences)
Also, the idea that there is some universal rule of 'what should be checked in to source control' that applies to EVERYTHING from personal projects to corporate internal monorepos to open source projects to undergrad joint coding projects to video games is... absurd.
If I can provide machine readable documentation on how to get your VSCode environment set up (in the form of a .vscode/extensions.json file), isn't that strictly better than merely human-readable documentation in README.md under a 'Recommended VSCode Extensions to work with this project' header?
See also: https://code.visualstudio.com/docs/getstarted/settings#_sett...
But then again, language-specific settings will trump all other settings. And that’s one way to override workspace-level settings in your user settings if you want.
Here’s a detailed list of all levels of settings in VS Code, ordered by precedence: https://code.visualstudio.com/docs/getstarted/settings#_sett...
I usually add something like specified in:
I add it to the repository settings, so all collogues have the same behavior.
Everyone aren't using all the freedesktop conventions, so no.
$ man git-config
It is however densely conditional wording -- could be simplified. *.sw?
Since I'm messy enough to sometimes end up with multiple of them for a few files. (Also, not messing with flash files in git, or in general...)But have since moved my vim swap files to ~/.vim/swap with `set directory=~/.vim/swap,.` in .vimrc.
~/.config/git/ignore
on Unixy platforms.So good.
> Don’t use the standard ignore rules (see gitignore[5]), but still use the ignore rules given with -e options from the command line.
git will take 3 files into consideration for "ignoring" files:
> $XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore
How I use them:
* ~/.gitignore: stuff I want to ignore everywhere (`/myNotes`, `.DS_STORE`, ...)
* <project>/.gitignore: stuff that should be ignore for this projects and shared with others
* <project>/.git/info/exclude; stuff for this project that only I want to ignore
** this is also super useful in combination with `git-bisect`
To move in to a new machine - unfortunately you can't git clone into a non-empty directory, but the commands to work around that are simple enough to remember.
[1]: https://github.com/BurntSushi/dotfiles/blob/965383e6eeb0bad4...
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`.
Edit: The flag is -N or --intent-to-add
alias ga="clear ; git add -p" is an alias i always seem to keep
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.
- 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.
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.
fza = "!git ls-files -m -o --exclude-standard | fzf -m --print0 | xargs -0 git add"
That lets you interactively choose which files to stage.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
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)
The main drawback is something I do from time-to-time which is nuking and re-creating directories.
Things like:
drafts/
backup/
*.bak
ignored/
etc.I don't really see the downside to just adding them to the tracked gitignore. If other people have a different convention and want to add these files/paths for some reason, it's easily discoverable to them why the files can't be added, and then we can have a discussion about what naming conventions we want.
"I see this guy has 'passwords/'" on his local machine, let's somehow sneakily merge new .gitignore to make them available publicly.
thanks for the tip, is there a way to hide files at root level? I want to hide some .env. files
You can also put local gitignore rules in .git/info/exclude , but i have a hard time remembering that exact path for some reason.