111–120 of 188 posts
>~/.config/git/ignore This never be considered as a solution. It only works on that PC, when working with a team, this approach is wrong in so many levels. I host my own Forgejo server/repos, it is just me but .gitignore just makes more sense. It is on the root of the project, and I only have one file to manage. No matter that PC/device I am using, they are automatically covered.
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…
as someone who deals with dep upgrades and forensics when trying to figure out a bug I would get _so mad_ if `git diff` didn't show the diffs to lock files. I get what you're saying about it being line noise but when you need it you need it!
We've adapted: - our CI and git hooks so that our dependency or .lock files are visible when they change, and error if they change inconsistently - and our team procedures to confine dependency updates to dedicated commits
The idea being that when you see one of those "messy" .lock file changes...you were expecting it. If you see one and are annoyed by it (like OP) that's actually a waving red flag that a dependency changed.
Earlier quoted context omitted.
As a bonus, you can (should?) version control your `~/.config` dir to enable future revisions and sharing.
You may need to have certain directories be excluded depending on the programs you use. For example, the default Chrome profile location is within ~/.config, which includes cache data that can be multiple gigabytes in size.
Earlier quoted context omitted.
git is a hell of a tool. It looks simple but is so beautifully versatile without being complex without being complex Uh, what?
What part of Enumerating objects: 15, done. Counting objects: 100% (15/15), done. Delta compression using up to 10 threads Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 1.43 KiB | 1.43 MiB/s, done. Total 8 (delta 7), reused 0 (delta 0), pack-reused 0 (from 0) remote: Resolving deltas: 100% (7/7), completed with 7 local objects. don't you understand?!
I just can't ever be confident the command I write will do the thing I expect it to...
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…
People are jumping on it being an important file to review. You don't want to ignore the diff. Even if that's true, you definitely do not want to attempt merge two lock files, and using the .gitattributes file to set the merge strategy is a good idea!
config.json merge=ours you may have a personal notes.txt file in a repository that you don’t want to check into git but you also don’t want to add to .gitignore because it’s unique to your workflow.
The exclude file lives in the .git directory of every Git repository but changes to it are not checked into Git
Earlier quoted context omitted.
As a Mac user, you should tell them how to do a better job.
This level of tribal antagonism over ten quite commonplace bytes is IMO entirely overcooked, but it is an excellent demonstration of 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.
Earlier quoted context omitted.
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.
The point is that it should not be massive.
Earlier quoted context omitted.
As a Mac user, you should tell them how to do a better job.
This level of tribal antagonism over ten quite commonplace bytes is IMO entirely overcooked, but it is an excellent demonstration of 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.
I assume that’s why some open source maintainers don’t bother either - if you haven’t even looked at your diff before submitting then why should they?
Earlier quoted context omitted.
> you just want to see that the file changed I check the diff for uv.lock (Python counterpart of package-lock.json) every time I merge a PR. It is important to know which direct or transient dependencies have been updated. We don't blindly bump all dependencies to the latest versions (you shouldn't either).
same - I check the changelog for every major (== minor if v0) and some minor version changes in most of my projects, including at work. I've caught quite a lot of would-have-broken-something changes, and opportunities for fixes/optimizations/etc by doing so. and sometimes they mention fixing a bug we didn't know we had, so we learned about it early before it corrupted too much data.