Rendered at 22:06:28 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
hungryhobbit 2 hours ago [-]
Fun article, but it leaves out my favorite "almost ignore" feature in Git: `.gitattributes`.
This file lets you specify that git should "ignore" the diff from certain files. For instance, Node projects have a `package-lock.json` that is pure noise from a Git standpoint (it's just massive amounts of diff specifying specific versions of libraries, and the real human-readable version is in a separate `package.json` file).
With `.gitattributes` in the root of your project, you can just add a line:
`package-lock.json -diff`
Now, that file will still get staged/committed (which you want) ... but when you `git diff` you won't see the massive amounts of pointless diff in that file.
clates 2 hours ago [-]
> that is pure noise from a Git standpoint
It shouldn't be noise. Don't update it if you're not intentionally trying to, otherwise you're exposing yourself to supply-chain risk for no reason. If you are regularly getting unexpected `package-lock.json` changes then you are doing something wrong.
po1nt 2 hours ago [-]
It's not about unexpected changes. It's about DX in git CLI. You don't want to see massive diffs that are basically unreadable for humans, you just want to see that the file changed.
gpvos 34 minutes ago [-]
DX = ? Developer experience maybe?
leleat 3 minutes ago [-]
There is also
git update-index --[no]-skip-worktree
for files that are already tracked. This can be useful for some local experimentation... it's just a bit annoying to use because it's not really surfaced anywhere by git (kinda). You need to remember that you set it; otherwise other operations like checkouts may be blocked.
kevincox 6 hours ago [-]
The global/user wide exclude is a feature that should be more widely known. I frequently have people submitting changes to add their IDE/OS/AI/... files to every project's .gitignore. They are almost always pleasantly surprised when I tell them that they can add them to their standard configuration and have them ignored everywhere without bothering every project and without risk of accidentally committing them on a project where they haven't updated the .gitignore yet.
My general rule is that in-repo .gitignore should only be used for repo-specific things (build outputs, dependency folders, ...) and most user tools should be in their own user config.
Anon1096 4 hours ago [-]
You frequently having to tell people about a global configuration gitignore is an obvious consequence of "My general rule is that in-repo .gitignore should only be used for repo-specific things". It wastes less of everyone's time to just gitignore them in every project.
kodablah 3 hours ago [-]
This mindset is how you get lots of IDE/dev-env-specific/platform-specific cruft inside of repos instead of pristine repos. It makes both contribution and maintenance difficult over time. While less of an extreme issue as IDE/dev-env-specific/platform-specific hacks/scripts littering the repo, gitignore entries should be generally justifiable, not ever-growing cruft to be added by each developer specific to their situation.
2 hours ago [-]
saagarjha 2 hours ago [-]
I’d really only like my projects to talk about things relevant to the project, instead of having to think about the fact that you might be using Qt Creator.
fluoridation 49 minutes ago [-]
Eh. It's a tool, not a document. It should contain things that help development.
mikepurvis 3 hours ago [-]
Fair, but it depends how uniform the culture is around a particular project. Is it haskell and everyone is using emacs? Sure, include those. But trying to chase the requirements of half a dozen different editors is silly.
ffsm8 3 hours ago [-]
That's the thing though, you don't need to do that.
Whoever is using whatever editor can do it, so the effort is distributed to whoever cares to contribute.
There is no meaningful penalty for it to be not up-to-date. There is only a benefit for people who come in when it's already configured, as they don't need to configure anything anymore.
(I say that but I'm using a global ignore too for eg ai configuration like skills as I like to half-ass them before discarding again)
antonvs 2 hours ago [-]
The penalty is a long file full of cruft that's effectively impossible to ever clean up.
wccrawford 6 hours ago [-]
I've always added it to the project's gitignore because I want to make sure nobody else adds those to the project, either, out of ignorance. I'm mainly doing it out of kindness to them, because I am definitely removing them from git again and it's going to cause them some pain.
In the future, I think I might just be less nice about it. I dunno.
xboxnolifes 3 hours ago [-]
This is how I see it. The more contributors you have with a code base, the larger the possibility that one person will mistakenly commit something that could have easily been avoided by just preemptively adding it to the .gitignore.
You cant preempt every file or folder, but its almost no effort to catch the obvious ones.
nomel 4 hours ago [-]
Yeap. To reduce pain, you need to work with reality rather than ideals. If you work with a big group, you either add a few lines into your gitignore, or you write code to check for those very same files in your CI/PR system, because you're tired of reversing commits and rejecting PRs because you're the only one that cares about a few extra files.
eyelidlessness 5 hours ago [-]
I’m not sure kindness is the best framing. At least, not in terms of being nice to any particular person who might commit unwanted files by mistake.
It’s one of several tools a project can use to ensure quality, alongside eg linters and formatters. Automating those (in this case by defaulting to the expected outcome) reduces friction on basically every operation anyone might do in a project, in any context.
Through the lens of kindness, it benefits you as well as your team… and ultimately everyone else downstream, since you’re all not wasting time and cognitive load on trivially preventable mistakes.
xboxnolifes 3 hours ago [-]
This is how I see it. The more contributors you have with a code base, the larger the possibility that at least one person will mistakenly commit something that could have easily been avoided by just preemptively adding it to the project .gitignore.
You cant prompt every file or folder, but its almost no effort to catch the obvious ones.
8cvor6j844qw_d6 4 hours ago [-]
I prefer gitignore since it survives dev container rebuilds.
I can set a creation script or volume to restore/persist configs if I must avoid gitignore. However, that's an extra script or devcontainer mounts config over a gitignore line.
mvanbaak 4 hours ago [-]
In my opinion (which might not be shared by everyone) this is a you problem.
Developers in the team not using decontainers should not have to worry about your environment.
ide/local-env stuff should be ignored in the users git setup, everything that the repo creates (build artifacts, environment files etc) should be in the repo.
arcanemachiner 3 hours ago [-]
Interesting case. For the global ignore file, couldn't you just bind-mount that into the container?
paulddraper 3 hours ago [-]
> However, that's an extra script or devcontainer mounts config over a gitignore line.
paulddraper 3 hours ago [-]
That's an interesting case, where you are crossing operating systems.
---
That said, the easier change is still a one/two line bind mount that trying to exhaustively list ignored directories for every IDE or tool under the sun.
mvdtnz 3 hours ago [-]
Do you not see the conflict between seeing the same incorrect behaviour again and again, and having a firm rule that expressly forbids the easiest fix to that behaviour?
paulddraper 3 hours ago [-]
.DS_Store
hk1337 8 hours ago [-]
~/.config/git/ignore and ~/.config/git/config is the proper place for your global git config and ignore instead of creating a ~/.gitignore_global and changing the config. IMO.
my dotfiles are a lot smaller at the root level taking advantage of the ~/.config/ for a lot more things.
the git exclude isn't used as much because it doesn't get committed to the repository so you'd have to recreate it each time you wanted to use it. that doesn't mean they're bad just why they are not used.
coryrc 28 minutes ago [-]
Or use ~/.cvsignore for all the other things which use that same file.
b40d-48b2-979e 7 hours ago [-]
As a bonus, you can (should?) version control your `~/.config` dir to enable future revisions and sharing.
hk1337 7 hours ago [-]
Absolutely. On that subject, I prefer the Atlassian method for storing dotfiles in git but sometimes I feel like it's Mootools vs jQuery all over again.
judofyr 8 hours ago [-]
Not sure where I picked up this, but I’ve added this to my global Git ignore:
attic
That way you can just create an attic directory in any project where you can keep random stuff that should never be committed. I’ve yet to find a repo which actually has such a directory checker in.
deathanatos 46 seconds ago [-]
You can also sort of invert this, but you have to do it on a case by case basis.
Let's say you have a directory like attic; you can put inside a `attic/.gitignore`:
/**
& then that directory (and anything in it) is ignored, including the ignore file itself.
I usually name my version of this directory the single character U+1F4A9, which HN refuses to permit me to put in a comment ;)
weinzierl 6 hours ago [-]
Mine is
aux
and I hide it by putting a .gitignore in it that just contains am asterisk (*), nothing else, that way it ignores itself and anything in it.
trinix912 4 hours ago [-]
Does Windows still go crazy when making an “aux” or “con” directory or has this been patched?
fluoridation 47 minutes ago [-]
It's never going to be patched because it's not considered a bug.
metadat 5 hours ago [-]
Genius idea.
addedGone 4 hours ago [-]
The next Elon musk.
williamjackson 7 hours ago [-]
I do this too! But I call it `.local`
zahlman 6 hours ago [-]
I have a new-repository script that creates a .local directory and puts a .gitignore with just `*` in it.
bflesch 5 hours ago [-]
Doesn't git automatically exclude all files starting with a dot?
micael_dias 5 hours ago [-]
No
thewisenerd 2 hours ago [-]
mine's `scratch/`
hasn't tripped me up (yet)
lmf4lol 3 hours ago [-]
Wow! How did I not know this? I am a professional software dev for 20 years… and only ever used .gitignore !
I just realized that I never even „asked“ myself if there might exist a better way than to clutter .gitignore with all kinds of specific excluded only relevant to me. I just accepted the world as it appeared to me…
And Today, it got s little bit better :-)
dofm 5 hours ago [-]
Re: per-user ignores:
> For example, if you’re on macOS, adding .DS_Store here would be ideal.
As long as every Mac user on your project does. If you have more than one, it may be better off taken out of everyone's hands.
tremon 3 hours ago [-]
That's a very particular way to frame the few vs the many. If a single macOS user works on ten different projects, should all ten projects add that line, or may things be better off taken out of each project's hands and on that single user?
2 hours ago [-]
dofm 2 hours ago [-]
I mean sure, if you're this worried about ten bytes and prefer instead to spend time endlessly lecturing new Mac-based submitters about the additional overhead of supporting Mac-based submitters.
saagarjha 2 hours ago [-]
As a Mac user, you should tell them how to do a better job.
dofm 9 minutes ago [-]
This level of tribal antagonism over ten quite commonplace bytes is IMO entirely overcooked, but it is an excellent demonstration of
Me, I am pragmatic. I have set this in my local config and I've added it to my repos to be certain. Because it's ten bytes.
2 hours ago [-]
bryancoxwell 8 hours ago [-]
I use the ever living hell out of .git/info/exclude. Works great for scripts/Makefiles I only want locally and collaborators wouldn’t care about or be able to use.
RSHEPP 8 hours ago [-]
Interested in examples of the types of scripts others collaborators wouldn't be able to use? Like scripts for PR workflows?
junon 8 hours ago [-]
Usually when I'm working in one part of the codebase and I have sample data or something at a specific path on my local machine and Im testing the same thing over and over again will I make a Makefile or something and info/exclude it to help me keep focused. That's one way I use it.
bryancoxwell 7 hours ago [-]
Yeah this is pretty much it.
digikata 6 hours ago [-]
For quite a while, I've have had a shell fcn that will take all the untracked files listed in a git status, and push them to .git/info/exclude. Generally applied after an add+commit of everything I do want to go generally into the repo.
wpollock 7 hours ago [-]
One point of clarification: with git, "global" means per-user, not "machine-wide. (I never understood why "--global" wasn't better named, maybe "--user".) That's why these pathnames are in a user's home (the "~" means the current user's home directory).
Machine-wide configuration is called "system" in git, and generally lives under "/etc".
Or block large changes, because binary mods are often larger than a real diff.
barbazoo 7 hours ago [-]
Exclude sounds like a recipe for sadness.
globular-toast 6 hours ago [-]
Magit has good support for these other methods. You press <i> and then select if you want the ignore to be shared (.gitignore) or private (.git/info/exclude).
uptown 6 hours ago [-]
Not really news. I worked with dozens of developers who have managed to ignore files in Git.
allows for remote specific configs, overriding say email or other required options depending on where you send contributions - without having to have per repo config
works for dir too
[includeIf "gitdir:/home/user/src/work1/"]
Git is REAL bitch about exact syntax here; the first snippet won't work with just :*, it needs :/* ; the second won't work without trailing slash
This file lets you specify that git should "ignore" the diff from certain files. For instance, Node projects have a `package-lock.json` that is pure noise from a Git standpoint (it's just massive amounts of diff specifying specific versions of libraries, and the real human-readable version is in a separate `package.json` file).
With `.gitattributes` in the root of your project, you can just add a line:
`package-lock.json -diff`
Now, that file will still get staged/committed (which you want) ... but when you `git diff` you won't see the massive amounts of pointless diff in that file.
It shouldn't be noise. Don't update it if you're not intentionally trying to, otherwise you're exposing yourself to supply-chain risk for no reason. If you are regularly getting unexpected `package-lock.json` changes then you are doing something wrong.
My general rule is that in-repo .gitignore should only be used for repo-specific things (build outputs, dependency folders, ...) and most user tools should be in their own user config.
There is no meaningful penalty for it to be not up-to-date. There is only a benefit for people who come in when it's already configured, as they don't need to configure anything anymore.
(I say that but I'm using a global ignore too for eg ai configuration like skills as I like to half-ass them before discarding again)
In the future, I think I might just be less nice about it. I dunno.
You cant preempt every file or folder, but its almost no effort to catch the obvious ones.
It’s one of several tools a project can use to ensure quality, alongside eg linters and formatters. Automating those (in this case by defaulting to the expected outcome) reduces friction on basically every operation anyone might do in a project, in any context.
Through the lens of kindness, it benefits you as well as your team… and ultimately everyone else downstream, since you’re all not wasting time and cognitive load on trivially preventable mistakes.
You cant prompt every file or folder, but its almost no effort to catch the obvious ones.
I can set a creation script or volume to restore/persist configs if I must avoid gitignore. However, that's an extra script or devcontainer mounts config over a gitignore line.
---
That said, the easier change is still a one/two line bind mount that trying to exhaustively list ignored directories for every IDE or tool under the sun.
my dotfiles are a lot smaller at the root level taking advantage of the ~/.config/ for a lot more things.
the git exclude isn't used as much because it doesn't get committed to the repository so you'd have to recreate it each time you wanted to use it. that doesn't mean they're bad just why they are not used.
Let's say you have a directory like attic; you can put inside a `attic/.gitignore`:
& then that directory (and anything in it) is ignored, including the ignore file itself.I usually name my version of this directory the single character U+1F4A9, which HN refuses to permit me to put in a comment ;)
hasn't tripped me up (yet)
I just realized that I never even „asked“ myself if there might exist a better way than to clutter .gitignore with all kinds of specific excluded only relevant to me. I just accepted the world as it appeared to me…
And Today, it got s little bit better :-)
> For example, if you’re on macOS, adding .DS_Store here would be ideal.
As long as every Mac user on your project does. If you have more than one, it may be better off taken out of everyone's hands.
https://en.wikipedia.org/wiki/Narcissism_of_small_difference...
Me, I am pragmatic. I have set this in my local config and I've added it to my repos to be certain. Because it's ten bytes.
Machine-wide configuration is called "system" in git, and generally lives under "/etc".
Ok, sometimes a more vivid and visually explanatory style would help, but here still Google is your friend for individual concepts.
One of the best resources there is. git is a hell of a tool. It looks simple but is so beautifully versatile without being complex or not deductive.
Asking aLlm is the new google
Set a global hooks dir, and then block binary files in pre-commit by using file or checking the git index
Or block large changes, because binary mods are often larger than a real diff.works for dir too
Git is REAL bitch about exact syntax here; the first snippet won't work with just :*, it needs :/* ; the second won't work without trailing slash