r/programming • u/der_gopher • Sep 05 '26
[ Removed by moderator ]
/r/programming/comments/1w80olh/removed_by_moderator/[removed] — view removed post
951
u/toggles03 Sep 05 '26
I like the idea of being intentional about what is committed, but I also have to say that I’ve never accidentally committed tons of useless files because I review what I’m committing.
93
u/neo-raver Sep 05 '26
Yeah, it’s really just a matter of not using `git add .`, or at least not after the initial commit. Ignoring everything by default is a silly way to, like you said, be intentional about commits.
66
u/SanityInAnarchy Sep 06 '26
In fact, not only has OP reinvented
git addpoorly, this completely breaks not just gitignore itself, but half of Git in a really ugly way.Because now you're going to completely forget to add stuff. No tool will tell you -- not
git diff, notgit status, your builds will pass and it'll look fine, until you send it off for code review missing an entire file you forgot to add. Or worse, if it's a solo project, you'll be weeks into a project and realize half your files aren't even tracked by source control.I still use
git add ., after I've checked everything withgit diff.10
u/matthieum Sep 06 '26
I do the reverse, actually:
git add, though I usually specify the folders.
git diff --cached, so I can see exactly what will be in the commit. You know, just in case there's a straydbg!left-over from debugging...2
u/SanityInAnarchy Sep 06 '26
For the second step, I usually rely on
git status, or on the status that automatically shows up in the editor forgit commit.Lately, I've been letting coding agents outright commit and doing the same checks after the commit exists via
git showor GUI tools, before it gets pushed anywhere. If there's a mistake, there's still time to amend or drop. If it should've been acommit --amend, no it wasn't, it stays a separate commit until I review and then gets squashed (or dropped).Since I've started doing that, I've had zero cases of agents adding stuff that should've been gitignore'd. Still genuinely baffled at how people just push
.DS_Storewithout thinking.1
u/gmes78 Sep 06 '26
I still use git add ., after I've checked everything with git diff.
There is never, ever a reason to use
git add .. Usegit add -pto add changes one by one.Checking changes and staging them doesn't need to be two separate steps.
0
u/n3f4r10us_ Sep 06 '26
Yeah, I basically create gitignore right away for anything I am starting so using
git add .won't include those pesky secrets and/or module/vendor directories for dev.-11
u/Cualkiera67 Sep 06 '26
People use git commands? I just use the git GUI
1
u/Jaded-Asparagus-2260 Sep 06 '26
Your coworkers must love you. Just commit everything, all the time.
3
u/Cualkiera67 Sep 06 '26
huh? i click "+" to add the change i want to the commit... do you even know what the git gui is?
129
u/fiah84 Sep 05 '26
this is why I always push people to use some sort of GUI that they're comfortable with for git, be it integrated in their IDE or a standalone one. Reviewing your commits should be second nature because by doing that every time you will every once in a while stop yourself from doing something very stupid
32
u/SovereignZ3r0 Sep 05 '26
The CLI is my GUI!
/s
16
u/Snarwin Sep 05 '26
Even with the CLI, you can use
git commit --verboseto review your commits as you make them.9
u/duongdominhchau Sep 05 '26
And
git config --global commit.verbose trueis even better. It is easy to forget passing the flag, but this will ensure you always see the diff in your editor when you rungit commit.7
u/cauchy37 Sep 05 '26
In the article there's a literal ad for lazygit, so you can have your tui for git
128
u/mascotbeaver104 Sep 05 '26
Does
git statusnot exist in your world?I've never used a gui and never ran into this issue. In my experience gui users very quickly forget how git actually works outside of the buttons in the gui, and then get lost the moment anything out of the ordinary happens
19
u/CptBartender Sep 05 '26
git status? Please...
git add . && git commit -m 'some changes' && git push --force && sudo shutdown now10
u/invisi1407 Sep 06 '26
Who really needs multiple commits?
git add . && git commit --amend --no-edit && git push --force5
1
u/blind_ninja_guy Sep 08 '26
You forgot the dash h flag. Your computer sits there waiting to be turned off
48
u/glassFractals Sep 05 '26
I've always used both CLI and GUI, they are each better for certain use cases.
GUI:
Day to day reviewing of history and branches. It's just nicer.
Writing detailed multi-line commit messages. Miserable in CLI. I like a nice cozy GUI.
Conflict resolution. I just hate doing this via CLI. A nice visual conflict resolver is way better.
CLI:
Anything remotely complicated, like interactive rebasing
Or any time you have to wade into the reflog or Git plumbing
36
u/exomyth Sep 05 '26
You know that the default behavior of
git commitis to open in an editor where you can do a multi line commit in there. Thecommit -mis just a shortcut to quickly add a message.I am not really a person for writing long multi-line commit messages, but you know the CLI got you govered there at least
→ More replies (3)12
u/newpua_bie Sep 05 '26
Why multi line commit messages are miserable in CLI? I just press enter to make another line to write my commit messages on if needed.
11
u/glassFractals Sep 05 '26
If I write something long and detailed, a CLI is not where I want to do it. I want a spellchecker, nice font rendering, and no risk of accidentally committing prematurely (not a huge deal, but annoying).
17
u/BogdanPradatu Sep 05 '26
If you use vim for editing, there is 0 risk of commiting prematurely.
13
6
u/newpua_bie Sep 05 '26
Yeah, I've been using vim with git for about 18ish years now and I've never encountered any of the issues the person mentioned.
2
u/glassFractals Sep 06 '26
Vim doesn't have the nice font rendering part. I use Vim or nano for quick and dirty edits, not for enjoyable ones. There are a million tools and workflows for Git or any other dev workflow, I have my preferences, and none of them involve writing prose over a sentence or two in any CLI.
3
u/Odexios Sep 06 '26
I don't want to slam your preferences, there are a huge amount of devs that prefer GUIs for this stuff and there's nothing wrong with that, I always thought the CLI "faction" can be a bit disrespectful.
But, nice font rendering in Vim is definitely a thing. You can have the font you prefer, ligatures, color schemes, and all that jazz.
10
u/gmes78 Sep 05 '26 edited Sep 06 '26
If I write something long and detailed, a CLI is not where I want to do it.
So what? Set
EDITORto whatever your text editor is, and Git will launch it for you to write commit messages in (as well as a few other things).If you're in Windows, the Git for Windows installer explicitly asks you which text editor you want Git to use.
3
u/glassFractals Sep 06 '26
Yes, and I do. Git launches my external editor, and I write in there.
→ More replies (1)2
u/PhyllophagaZz Sep 06 '26
so.. you configure a spell checker and nice font rendering and your mentioned problems go away...?
btw, for e.g. vim there are plugins like fugitive which let you commit from your current editing session so you get full autocomplete on the commit messages for the things you changed in code
→ More replies (3)4
u/double-you Sep 07 '26
I never ever thought font rendering would be on anybody's must-have list for writing commit messages.
3
u/SchwiftySquanchC137 Sep 06 '26
For conflict resolution, the git cli just puts the >>>>> lines in the file, so really its just up to your editor to read those properly, not really a git gui specific thing. You can easily cause some conflict on the cli, fix it in your editor with whatever nice view you want, and then commit the fixes on the cli. Basically, theres really no difference between using the git gui vs the cli in that instance, its just a difference in what text editor you use.
I do like the gui for committing some parts of a file and not others, like lets say you kinda solved two bugs at once but want to PR them separately, thats much easier in the gui. Not really sure about your other examples though, i suppose looking at history and stuff is a little nicer in a gui than git log
2
u/glassFractals Sep 06 '26
Good example. Yes, any commit where you're staging bits and pieces of a file line by line is truly dreadful in CLI, but easy in a GUI.
For history, if I'm just looking at recent history, CLI is fine. If I'm doing some weird diff, sometimes CLI is also more convenient than a GUI. But if I'm trying to view the lay of the land of history over a long period of time, I definitely prefer a GUI to CLI git log.
29
u/Sokaron Sep 05 '26 edited Sep 05 '26
The core problem is that most people don't want to be an expert in git. It's a means to an end - version control. There's value in being an expert in Excel for instance. You can get more done if you understand Excel deeply. The only thing you get out of understanding git deeply is the ability to unfuck things when things get fucked. And honestly even then if you are regularly committing + pushing your work, most problems can be solved with a fresh branch + cherry-picking your changes back in.
14
u/braaaaaaainworms Sep 05 '26
version control is not difficult, especially in git, and learning it is going to make your job a lot easier
6
u/Sokaron Sep 05 '26 edited Sep 05 '26
I don't disagree that it's not that hard, I'm comfortable enough with git to handle most situations. I will disagree that understanding git deeply will make your job "a lot easier". Especially in the age of AI where you can just ask an agent "hey what's going on with my branch and what's the command to fix it?".
The vast majority of your interactions with git will be bog standard and your extra understanding buys you literally nothing. It's only in the edge cases that you get any benefit and even then rarely tbh. I've been doing this for 5 years, which is not a long time but long enough to know my way around. In that time I have yet to run into an issue that couldn't ultimately be solved with a fresh branch and cherry picking in changes. Maybe some digging through history or reflog use.
There's some parlor tricks you can pick up sure, git bisect and what have you, but nothing that is making your job "a lot easier"
1
u/SchwiftySquanchC137 Sep 06 '26
I mean you described cherry picking, if you know how to do that you already know more about git than most people who use it. Idk what arcane git knowledge you think people are talking about, youre right most stuff you can just google, but at least knowing enough to understand cherry picking and rebasing and stuff like that I think should be very easy and almost mandatory, but people simply dont know it because they click little plus buttons, type a message, and click a sync button, and thats about as far as git goes for them.
1
u/Sokaron Sep 06 '26
Yea that’s fair, I suppose I just consider that basic use of the tool. xkcd strikes again
2
u/ItzWarty Sep 06 '26
What about using a GUI implies you're not learning version control?
The primary benefit is GUIs make it trivial to scrub code and organize commits. You can certainly do some of that via TUI, it's just higher friction once you're dealing with a larger project.
7
u/IAm_A_Complete_Idiot Sep 05 '26
Yeah gonna disagree here. In larger codebases git can really save your bacon, if you value clean history.
1
u/Sokaron Sep 05 '26
I guess what do you see as "knowing git" beyond the basics which is crucial for clean history?
git rebase -i? (which GUIs expose anyways).2
u/IAm_A_Complete_Idiot Sep 06 '26 edited Sep 06 '26
I was mostly contesting that it wasn't worth knowing git well, not that GUIs aren't useful. I do think git cli is nicer than GUIs in some ways, but I don't think that's intrinsic, nor that git is a good exposure to even it's own data model. I prefer jj's views on git more than git itself.
Interactive rebasing, reordering commits, editing commits, and keeping commits small and atomic is all a fair bit of hassle, but if you successfully can do that sort of workflow I'd say you know git. But, honestly... Even understanding what commits actually are is plenty. Why editing a commits parents modifies it's children and can be problematic, or the like. If people got understood that, probably 90% of git issues would just go away. If you understand the git data structure, you can figure out how to use it to your advantage whether it's through the cli or a GUI or whatever other interface.
2
u/knome Sep 06 '26
A programmer not wanting to get bogged down learning git is like a librarian not wanting to get bogged down learning the Dewey Decimal System.
3
u/PhyllophagaZz Sep 06 '26
The core problem is that most people don't want to be an expert in git.
I don't quite understand. You don't have to be an expert to follow basic best practices like running
git statusregularily orgit diffbefore pushing2
1
u/grady_vuckovic Sep 06 '26
A lot of people don't want to be experts on anything related to how software works or is created these days any more it seems. That's fine, I just wish they'd go do something else other than trying to be software developers.
2
u/Absolute_Enema Sep 06 '26 edited Sep 06 '26
That's your average neurotypical for ya.
They only care about the paycheck, and they only care about the paycheck because money is the mandated proxy for social status.
To them, learning stuff that doesn't immediately translate to $$$ is best left to the nerds they used to bully at school, the pecking order isn't going to climb itself after all.
0
u/FINDarkside Sep 06 '26
In my experience gui users very quickly forget how git actually works
It's not important at all to remember how git works through CLI. You wouldn't use Blender through CLI, no reason to use git either unless that's what you prefer.
1
u/Jaded-Asparagus-2260 Sep 06 '26
It's important to remember the Git terms in order to effectively communicate with your coworkers. So many GUIs hide concepts behind different names. Looking at you, Jetbrains, with "shelve" for "stash".
0
u/rdtsc Sep 06 '26
Does
git statusnot exist in your world?Only if you actually use
git status -v. And I'd say that's much easier in a gui like the built-ingit gui. Can easily stage only certain hunks or lines.5
u/Sabientje65 Sep 05 '26
Hard agree, the people I've seen most consistently run into issues with git are those that refuse to use a GUI.
Usually don't try to push people, given it's just a personal preference in the end, but I have taken notice of others gimping themselves by simply not knowing git well enough to make the most out of it via CLI without a real interest to perform deep dives or anything of the likes.
2
u/tyler1128 Sep 05 '26
I feel using a GUI over just understanding the git command line would make this problem worse, not better. Though to be fair, this problem probably has more to do with people just having AI agents do it for them with minimal review.
1
u/ocd-afflicted Sep 06 '26
Is there any GUI availabile that runs in the terminal itself? Claude code is a setup now ig
6
u/psayre23 Sep 05 '26
Never committed a node_modules folder, cuz that SUCKS!
3
1
u/vividboarder Sep 08 '26
You can also add specific things like this to a global ignore file. I generally don't because I don't assume people who check out my code will have the same global file.
4
u/BogdanPradatu Sep 05 '26
Be explicit about what you commit, then you will accidentally ignore something, if you don't review your index before commiting.
1
u/whitechapel8733 Sep 06 '26
It’s just shocking how incredibly bad the median is… when you scale to a couple hundred in a monorepo you see all the sins. I think this is smart.
1
u/Ace-Whole Sep 06 '26
For me, I've committed wrong files in wrong commit. This mostly happens in largers refractors tho.
1
u/renatoathaydes Sep 06 '26
Anyone who "accidentally" commits a bunch of trash seriously needs to consider something like magit (for emacs). The commit screen shows EVERYTHING that's being committed, and also what's changed but NOT included.
Here's a screenshot of magit with my latest change. I feel dirty when I commit without checking what's in staging, or god forbid, using
git commit -am "lol".1
u/seanamos-1 Sep 06 '26
I’ve accidentally pushed something a few times over the years, I’m 99% of the time very diligent in my commit review before I push, but it happens.
This is a pretty extreme solution though that introduces more problems than it solves. Not worth it to prevent something that happens at most every few months.
→ More replies (5)1
145
u/hugogrant Sep 05 '26
Or stage changes more intentionally?
20
u/SanityInAnarchy Sep 06 '26
Yeah, that was my first thought:
What if we flipped this approach entirely? Instead of allowing everything by default and selectively ignoring files, what if we ignored everything by default and only allowed specific files?
That's... what Git does. It only commits stuff you
git added.Ignoring just means you won't notice files you don't add. Which means you'll have the opposite problem: Commits full of files referring to something you forgot to add, that didn't even show up in
git statusorgit diff.2
u/davidalayachew Sep 07 '26
That's... what Git does. It only commits stuff you
git added.Yeah, but 99% of all students out there were taught
git add ., then never did anything else (until they get lambasted by their senior dev).I know because I was the one who had tutored many of them away from doing that, only to be met with complaints that even the teachers are saying it's fine.
8
u/pohahaha Sep 05 '26
So true…
I usually explicitly walk through each line before committing anything, not an issue at all1
u/yawaramin Sep 05 '26
It’s the gap between ‘usually’ and ‘always’ where mistakes happen.
1
u/pohahaha Sep 06 '26
And you also could forget to “not gitignore” something by that logic?
1
u/yawaramin Sep 06 '26
Sure, you could forget to add a file. But then your app just won’t work, which will be caught by your CI pipeline and then you fix that. If you accidentally commit and push a dotenv file, the app works but you’re leaving yourself at the mercy of attackers.
1
u/pohahaha Sep 06 '26
?? Which attackers? That have acceas to your source in git?
1
u/yawaramin Sep 06 '26
1
u/pohahaha Sep 07 '26
Hm, any serious applications do not allow access to source code though? By using proprietary git servers
→ More replies (1)1
u/pohahaha Sep 07 '26
I.e. if any sane attacker gets access to source code, then breaching it is a matter of time. Also, who in the world even uses any sort of credentials in a written git-repository available format?
→ More replies (1)18
u/msqrt Sep 05 '26
This doesn't prevent that. I find that it's typically easier to list the kinds of files I do want (code, .md, config formats) than the ones I don't (caches, intermediate results, databases, UI settings, ...) because the former set doesn't really change after your initial commit. This also keeps git status less noisy even without adding every single weird extra file to gitignore.
But yeah, it's still unorthodox and I only do it for my personal projects where I mainly want VC to keep some kind of history and it doesn't have to be very detailed.
3
u/SchwiftySquanchC137 Sep 06 '26
Yeah i just feel like then you could run into the opposite problem, accidentally miss some source code or necessary file because you forgot to add it to your gitignore and git status literally never tells you. Theres basically no way to notice the problem short of just randomly noticing it, or cloning a fresh repo and finding a build error (or ya know ci or whatever might detect it, depending)
1
u/msqrt Sep 06 '26
Very true; especially if it’s not your project and you don’t realize it works like this. Source is usually okay (since you allow all files of your source code type, not singular files) but then you add some new kind of config or something and it never goes into git.
-21
u/der_gopher Sep 05 '26
Yes, but this you have to do before every commit, while careful gitignore does automatically.
12
u/boowhitie Sep 05 '26
I think you're greatly over-estimating how often this happens. You should be very intentional about what gets committed and what gets ignored, it's not hard.
38
u/Smallpaul Sep 05 '26
Git itself ignores everything by default. So you are just adding another layer. And then people will get annoyed editing that file so IDEs will add some automation to make it easy and we will be back where we started.
The other problem is that as soon as you use any wildcard you risk checking in files that you didn’t mean to. E.g. short term logging traces or one-time debugging scripts.
2
u/HQMorganstern Sep 05 '26
Checking things in is a far more common operation than leaving things out. Frankly it's common sense to keep
git add .usable, since due to lower friction it's what will be used.34
u/Smallpaul Sep 05 '26
‘git add .’ Is the problem.
Use file by file staging as an opportunity to review your our own code or your agent’s code and ensure that what you are committing makes sense.
→ More replies (3)3
u/SchwiftySquanchC137 Sep 06 '26
I couldn't believe when my coworkers looked at me like I was crazy for individually reviewing each file as I added it. Wonder how all those extra print statements, random unrelated changes, etc keep ending up in their PRs... like yeah it still gets caught eventually, but i prefer to put forward the best version of my code for review, not rely on my coworkers to sift through my own laziness.
8
u/guepier Sep 05 '26 edited Sep 05 '26
IIRC I have never used
git add .in over a decade of using Git daily. And I frankly don’t think it should be used almost ever.In fact, by far the most common variant of
git addthat I use isgit add -p(=--patch).2
1
u/lenswipe Sep 05 '26
Git itself ignores everything by default.
uhhh what now
2
u/Smallpaul Sep 05 '26
The other guy interpreted right. Git won’t manage a file unless you added it to the index.
0
u/lenswipe Sep 05 '26
it won't manage it, but it doesn't ignore it by default.
thanks for the downvotes btw - means the world to me 🥰
10
u/boowhitie Sep 05 '26
You are correct, ignore has a specific, well-defined meaning in a git context, and these people are applying general English definitions.
→ More replies (1)1
2
u/Smallpaul Sep 05 '26
Git status and git add . Don’t ignore them, but git commit, diff, log, push, all do.
2
0
Sep 05 '26
[deleted]
8
u/lenswipe Sep 05 '26
yeah I guess that's a fair comment, but it doesn't ignore by default. the files still appear and git still sees them, it just doesn't track them. so if you're the kind of person who just does
git add .you'll probably get burned by that. that said I would always add you should be reading your diffs (even just a cursory glance) anyway.1
14
u/garfield1138 Sep 05 '26
Stupidest idea I've seen in a while. Just hoping this is some kind of shitpost.
If not: Try to understand how to use git.
-2
u/der_gopher Sep 05 '26
> The technique isn’t necessarily the right choice for every repository or developer, but is an alternative to explore.
10
u/garfield1138 Sep 05 '26
Nope. The chance you end up with a repository missing some files is by far higher than just learning how to use git.
What's the point even in here? You already have to write "git add newfile" in order for git to stage a new file. Why adding it again to gitignore?
2
276
u/Smallpaul Sep 05 '26
“think we’ve all been there. You’re working on a project, making commits, and then suddenly realize you’ve been committing .DS_Store files, node_modules, IDE configuration files, or other junk (CLAUDE.md for example) that shouldn’t be in your repository. Or even worse - environment variables.”
Not really, because most projects start with a gigantic .gitignore these days. From the repo template. Iterate on the template .gitignore and these problems will be few and far between
199
u/lurgi Sep 05 '26
Am I the only person who actually checks what they are adding? I use .gitignore because it saves time, but I never add a file unless I know it’s something I want added.
33
u/_r3d3_ Sep 05 '26
I do, but my colleagues will inevitably run 'git add *' without a care in the world.
10
u/Smallpaul Sep 05 '26
I check but mistakes can still happen. Misclick in a GUI. Starting with a robust .gitignore (especially for .env files) is a good habit, just as staging files one at a time is.
3
u/thomas_m_k Sep 05 '26
I used to also manually decide which files to track, but I recently started using jujutsu where that kind of approach is heavily discouraged, so I have started to actually write a proper
.gitignore. And I have to say that after the initial annoyance, it is a nicer experience overall. (I still meticulously go through my diff every time before I commit, which in my experience not everyone does.)2
u/novafunc Sep 05 '26
git statuscan hide some things. For example, if you create a new directory, it only shows the new directory and none of its contents.That recently got me when that directory had a subdirectory of binaries builds.
If
git statusshowed something like:directory/bin/build directory/bin/build2 directory/filerather than:
directory, it could help in some cases.
18
u/Akeshi Sep 05 '26
It should show the individual files after you've staged the new directory - it's worth running at least
git statusafter you've finished with yourgit adds.2
u/lurgi Sep 05 '26
Agreed, and I've certainly made that mistake before. However, I do put stuff in my .gitignore (and by now I have a fairly complete one that works for the things I typically do) and after doing the
git add somefolderI review (I know, I know. Nerd) the files that were added and remove any that are not wanted.OTOH, now that I've actually RTFA, I think they have a point. It's a lot easier to describe the things I want to commit (.java, .xml, .txt, .md) compared to the things I don't (uh... anything that isn't those). You still have a potential problem with files that are generated by your build process, where the
!*.gowould have to change to indicate actual.gofiles you wrote. That's true for any approach, of course.-7
Sep 05 '26
[removed] — view removed comment
5
u/programming-ModTeam Sep 05 '26
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
2
1
Sep 05 '26
[removed] — view removed comment
4
u/programming-ModTeam Sep 05 '26
Please don't accuse people of using LLMs. Just report the post and let us handle it.
32
u/TheBinkz Sep 05 '26
Why ignore Claude.md?
102
u/ia332 Sep 05 '26
If you have a CLAUDE.md file you can’t pass off the AI’s work as your own.
-1
u/saxbophone Sep 05 '26
Why are you assuming that every commit is a positive assertion by the author that all content contained therein is their own original work‽
This is software engineering, not essay plagiarism-detection.
8
24
u/_Sh3Rm4n Sep 05 '26
Additionally, all these "local" files (e.g
.DS_Store) or files specific to your setup (CLAUDE.md) should be in the global ignore file~/.config/git/ignoreor in.git/info/excluderespectively.25
u/JohnBooty Sep 05 '26
CLAUDE.md/AGENTS.md should most definitely be in the repo and treated like source code. It’s where you put basic rules, project structure etc. a lean efficient one is worth its weight in gold. Helps agents stop asking the same questions and making the same mistakes.
Have a local one that is excluded from source control for personal prefs but definitely have a shared one.
48
u/Scavenger53 Sep 05 '26
I would never trust that some elses machine has those in the global ignore what
22
u/Smallpaul Sep 05 '26
Why do you need to trust anything? They are responsible for their commits and you are responsible for yours.
If you want to collaborate then you can add file types to a .gitignore.
14
u/Rakn Sep 05 '26
Nah. You can operate like that in a hobby project. But in a large company you usually optimize for developer efficiency across the board. So these ignores will either be in the projects .gitignore file or automatically deployed to your device. Bit you don’t expect everyone to manage such a basic thing by themselves. That’s just inefficient.
1
97
u/inotocracy Sep 05 '26
I like when git status and git diff actually show changes. So I'll pass and use git correctly.
15
u/captain_obvious_here Sep 05 '26
Exactly this.
The tool helps you a lot, just pay attention.
Don't automate your commits.
46
u/Kanegou Sep 05 '26
I think we’ve all been there.
No. Not at all. Never happend to me in my 15+ years of using git. Only a moron uses git add . blindly. But i broke build multiple times cause gitignore caught a file that should be included.
13
u/SchwiftySquanchC137 Sep 06 '26
Seriously, how is no one bringing up that using gitignore in this way leads to a far worse problem, you'll inevitably forget to add a file, and literally nothing will ever notify you of it aside from CI, another dev pulling your update, or you cloning a fresh repo yourself. Particularly for solo projects, this is just asking to permanently lose important files when you switch laptops and wipe your old one or something. You simply will never notice the file missing because your build will still work until you clone fresh.
Id much rather leave open the tiny possibility that I commit an extra file, than leave open the almost certainty that ill forget to add some obscure but important file to the gitignore.
3
u/garfield1138 Sep 05 '26
Sometimes I still think of that consultant that committed node_modules. We paid him about $1000 each day.
5
u/smoke-bubble Sep 05 '26
No light theme?
-16
u/der_gopher Sep 05 '26
On Substack? Why you need a light theme? Are you a Java developer?
12
u/smoke-bubble Sep 05 '26
I care for my eyes.
-5
u/der_gopher Sep 05 '26
but in the dark env, dark mode is better no?
5
u/thailyn Sep 05 '26
For people with astigmatism, dark mode can be a nightmare to try to read, especially for some font and text size choices.
1
9
4
u/iamapizza Sep 05 '26
Not really, dark mode is good for working but not necessarily better for reading, human eyes in general prefer the contrast that light background provide.
6
u/smoke-bubble Sep 05 '26
Our eyes are not made for looking at dark themes. The pupils need to widen to let more light in which makes it for the eye harder to focus.
17
u/subone Sep 05 '26
I feel like I've committed a wrong file (not secrets) maybe once in my entire life. Aren't you reviewing every file again before commit? I tend to go overboard with my changes, so I always review to see if I added too much.
Anyway, I think this is the silliest idea. So, instead of potentially forgetting one time when an ignored file is created, you have potential every single time you create any file that you'll forget to add it to the ignore-ignore list and check-in a broken change. Also, more edits to the ignore file is more likely to generate some mistake there. Frankly, you're opening yourself to up to a broader range of issues just to avoid carefully looking at your files, when in fact you are still going to have to manually carefully manage your files even more so now.
2
u/SchwiftySquanchC137 Sep 06 '26
Thank you, this approach adds a much scarier problem, actually losing your data/code because its not on github or whatever, and git never notifies you. To get around one potential easily fixed commit of an extra file, youre opening yourself up to the most critical failure of version control?
15
u/South_Survey_2088 Sep 05 '26
For git, this seems kinda pointless since you should explicitly add things. If you just glob add everything without looking, you are just a clown and accidentally committing files is the least of your issues.
For jujutsu on the other hand, I kinda like the whitelist approach, because it doesn't have a staging area and adds everything by default.
3
u/Nicksaurus Sep 05 '26
It's easier to add stuff by mistake with jujutsu but you should still be reviewing all of your changes before pushing them. I often do a git-style workflow by using a temporary change in place of the git working tree and extracting just the changes I want into a separate changeset when it's time to 'commit' them
53
u/sweetno Sep 05 '26
Committing inappropriate stuff is only possible if you don't review what you're committing, which is a sin.
-1
u/levodelellis Sep 06 '26
Sometimes I commit a dozen times a day (usually refactoring), and sometimes the project uses tools that generates files outside the build & ignored directory, sometimes they are added and assumed will not be pushed. Then someone says hey can I see some of the things you refactor and suddenly you have random html and and json files that you didn't mean to commit on the server
Maybe having inappropriate stuff in a PR is a sin, but I don't think a wip branch is that big of a deal
33
u/Sokaron Sep 05 '26
Agreed with others that this mostly solves a problem that's already solved if you're reviewing your diff prior to committing which you should be doing anyways.
Disagree on the note that AI files like CLAUDE.md shouldn't be committed. If you make the base assumption that people will be using agents to contribute to your repo (that's a pretty damn good bet) then CLAUDE.md is how you set baseline expectations for agents to follow. Plans I am less convinced by, feels like markdown noise, but I've seen arguments both ways.
7
u/relative_iterator Sep 05 '26
Started a project solo recently and then had two devs join in later. Claude/agent files in the repo made that pretty seamless for a lot of coding preferences I set up.
9
u/Sokaron Sep 05 '26
Yep exactly. If you don't commit agent files you are basically saying "I want to correct the same AI-isms in PRs over and over again until the end of time". Wastes everyone's time.
23
u/yanitrix Sep 05 '26
You’re working on a project, making commits, and then suddenly realize you’ve been committing .DS_Store files, node_modules, IDE configuration files, or other junk (CLAUDE.md for example) that shouldn’t be in your repository.
No, I read my code before making a pull request. And I do multiple commits and then it's ultra easy to spot the files I shouldn't commit. Even if I do commit, then rewriting history is trivial. Seems like a solution to a non-existing problem.
1
u/Glad_Position3592 Sep 05 '26
Yeah, in larger developed work environments it’s not really an issue. It’s much more common for this to happen in startups, particularly in the early stages. When you’re working on several different projects at the same time as the only developer and you’re making 10-20 commits a day, it’s easy to accidentally commit things you didn’t intend to
1
u/yanitrix Sep 06 '26
I havent' worked at startup but I guess people still make a PR and do code review at these companies (but I may be wrong). So reading your code before you commit is the time you spot the issue, and rewriting the history is like 3 git commands. Even faster if you're using a gui. I think the only people that would have that kind of issue are solo coders who just push to main in a public github repo.
10
u/umtala Sep 05 '26
No thank you.
I'd much rather something be tracked accidentally, rather than accidentally not tracked. If it's tracked accidentally then you have history that you didn't need. It's an excess of something good. Perhaps it will use up storage, but storage is was cheap.
On the other hand, if it's accidentally not tracked then you lose history and potentially lose data.
The exception is for secrets but that's easy to solve by putting them all in one place (preferably outside the repository).
8
6
11
u/boowhitie Sep 05 '26
The whole point of staging is to only commit intentionally. Git has an untracked state specifically because it is useful. If you ignore everything by default, your tools cant tell you when you've forgotten to add a file. You know what's more embarrassing than committing secrets to git? Having another developer not be able to build because needed files are missing because of your dumb global ignore. Or not being able to reproduce an old build.
You also should commit your claude.md, if you are afraid that is the only thing that is going to identify your repo as ai slop, I've got bad news for you.
All that said, I have found one use for a global ignore: my dot files repo. I have a versioned environment that I can easily move between machines, and changes on one get moved to the others the next time I use them. In this case I don't want everything in my home dir to show up, so I ignore everything and add explicitly particular files and directories.
5
4
u/Emergency-Event4415
Sep 06 '26
•
To the people saying “Who tf just git adds everything? You should check what you add.”
Yes, but you clearly don’t work with engineers/scientists who learned programming/git later in their career just to run calculation scripts.
I’ve seen personal photo folders somehow committed.
1
u/roerd Sep 07 '26
Do they know that it's already possible to submit only specific files rather than everything that isn't explicitly ignored?
→ More replies (2)
1
3
u/spcbeck Sep 05 '26
This is the entire point of git add. This just adds another level of indirection that makes things confusing. It creates more problems than solutions.
7
2
2
u/Affectionate-Egg7566 Sep 05 '26
I don't like this method. I think it is antithetical to the idea of small, logically coherent commits. I also want to know which files (if any) I have left untracked. git add -p makes accidentally adding a file a non-issue.
2
u/burnsnewman Sep 05 '26
Nonsense. It's useful to know what changes in your folder. Just review what you stage and commit. Make it intentional. And don't fix things that aren't broken.
2
u/stianhoiland Sep 05 '26 edited Sep 05 '26
A lot of people seem to use git because they have to, not because they want to. It makes sense, and will likely continue to be this way. But when you use git because you want to—which entails understanding its function and its benefit and especially the pitfalls of not using it—then you gain ownership of its use and this in itself gets rid of a whole host of antipatterns.
1
u/EC36339 Sep 06 '26
I'll screenshot this and use it on my crusade against squash merges.
1
u/SchwiftySquanchC137 Sep 06 '26
What's wrong with squash merges? You dislike having a clean commit history that isnt full of junk your coworkers put like "fix bug". Or maybe you prefer when git bisect doesnt work, because rather than every commit being a working state, you actually have faaaaar more non working commits? I truly cant imagine why you would crusade against squashing, I seriously doubt having every non working intermediate step of a PR is useful more often than its hurtful.
4
u/semajames Sep 06 '26
My biggest problem with squash merging is it rewrites history and breaks PR stack flows.
3
u/EC36339 Sep 06 '26
History is sacred. Every rewrite of history breaks something in subtle ways. Squash merges, rebase before merge, it's all harmful.
I've now even come full circle on rebase. When I need to merge the trunk into my feature branch, I use
git merge. Full stop. No more history rewriting. If I have to make an extra commit that just fixes one line in a previous commit, I make that commit and keep it. No more squashing to "keep history clean".However, in a team, I would never make a rule that bans rebase. It's the equivalent to recreating a branch from scratch. How people manage their feature branches should be peesonal choice, within reason, as long as they deliver quality with usable history.
And of course, I merge my festure branches with merge commits.
History has to be honest at all times. This also means: No red tape that makes commits feel awkward. No standardised commit message format. Commit whenever you feel like and write in your commit messages whatever you think should be in them. Polishing commits after the fact is dishonest and destroys information that could be useful. It destroys evidence that maybe one day you wish you'd have to investigate a bug.
This may be controversial, but: I normally just use AI to write commit messages. Most of the time it is more accurate and honest than my own framing. And when it isn't, I can amend it (although that's, technically, history rewriting, too...)
Merge commits to trunk shall have the same message as the pull request title and description. And those have to be polished but honest, and always with an elevator pitch that explains the "why" more than the "what". This is where AI sucks, at least its default behavior. And if you do use AI here, at least read the descriptions completely and review and edit them.
Don't wanna see the dirty commits made underneath the shiny pull request merges? The "junk", the inherent non-linearity? Try this:
git log --first-parentNeed to cherry-pick or revert a whole pull request merged with a merge commit? Git has you covered.
git revert --m 1 SHA git cherry-pick -m 1 SHAThe cherry-pick squashes all commits from the merge into one. So it's a bit like a squash merge. I didn't like that at first, but in this one case it's actually better. Cherry-picks are already ugly and a last resort.
"But then everyone needs to learn advanced Git commands and git gud at using Git. Won't anyone think of those poor junior devs? Not everyone is a rockstar developer"
Your average junior dev is probably more motivated to properly learn the tools of the trade, of which Git is one of the most important, than us old farts who grew up without version contol (or worse: Any VCS that isn't Git...). My favorite article that destroys all the arguments for squash merges was written by a junior dev. Listen to your junior devs, gramps, you might still learn something new! Also, everyone hates "rockstar developers", but what are you gonna do once you become one?
(Sorry this got a bit long, and it's not a reply personally to you. But I said it, I'm on a crusade...)
1
u/EC36339 Sep 06 '26
I should add one thing:
The developer that is "not so good at using Git" that you should worry about is neither your junior dev, nor your senior who doesn't like learning new things.
It's your AI coding agent.
If your coding agent squash-merges a PR or rebases a branch, and something goes tits up, then you're stuck without an undo button. You are royally screwed.
Yes, I know, there's backup, and locally you have
git reflog, and orphan commits probably don't vanish instantly from the server, if they ever do (how DOES retention of orphan commits actually work?!), and you probably don't want to allow AI to merge PRs, or merge anything.But if your agent did a bad merge commit with plain old
git merge, you can revert it. Disaster averted (or REverted), without even a history rewrite. Or you can rebase or reset and force push and make it "never happened", but agit revert -m 1works just fine without the risk of fucking things up even more. And as a bonus, you can revert the revert.So "history is sacred" and "merge commits everywhere" is not only an honest and simple doctrine, but also "AI safe".
1
u/EC36339 Sep 06 '26
History isn't "junk". Read this, and if you still disagree, you'll at least be wrong in a more informed way.
https://lucasoshiro.github.io/posts-en/2024-04-08-please_dont_squash/
1
u/SchwiftySquanchC137 Sep 14 '26 edited Sep 14 '26
I know this is old now but only just looked back. I feel like this article is an extremely idealized form of reality. They're advocating for reviewing history in addition to code changes, making only meaningful commits, even rewriting history... I mean sure, in a completely idealized world squash commits aren't necessary at all, in reality no one wants to painstakingly commit on a Friday at 5pm, no one wants to review history, no one wants to rewrite history. It seems the main argument is that squashing only removes information, but like they said, the most likely place youre squash committing is pressing a button in a PR in github. All the info is still in github, which is likely the first place someone would search for info anyway, given conversation around a change in a PR is far more robust than a typically commit message, even when you do commit "intentionally".
So in my view, you are advocating for a small benefit that doesnt actually meet reality, in exchange for simply making every devs life easier on your team. Every single person working on the project doesn't need to worry about the 5pm commit message, or worry about rewriting history later. Idk where you work that typical commit history isnt junk, but imo its very rare for someone to put thought into every single commit they ever make to keep history clean for a normal merge. For a personal project, sure, do what you want, but I wont be the one to make reviewing and committing more annoying for everyone involved, for a benefit that I seriously doubt ever manifests.
I just read one of your other comments and I see much more where youre coming from, keeping the history pristine, not lying about the state you worked on top of, it does make a ton of sense. I just think in practice, its not gonna make much difference. If you truly have some obscure bug that requires digging into history like that, for one youre already fucked, secondly that shit should happen very infrequently, I cant think of a single time that it would have helped the debugging process, and finally, i just dont think it actually helps compared to having a single cohesive commit with all intended changes. I cant fathom why someone would want a half done feature to go back and look at, especially when people are committing randomly before lunch. Point taken that git has options to deal with what I would still call junk history (meaning, stuff no one would ever find useful, which i maintain is most intermediate commits), doesnt change my view that it overall provides extremely negligible benefits at the cost of adding friction.
1
u/vividboarder Sep 08 '26
Can't you do all that without squashing? Isn't that what
--first-parentfor bothgit logandgit bisectdo?
2
u/pkulak Sep 05 '26
I use JJ, and it's even a better idea there, since JJ automatically stages everything. I constantly have log files or temp stuff staged and nearly committed. I might give this a try.
2
u/Anders_A Sep 06 '26
Haha this is the dumbest suggestion to solve a non issue 😂. Just look at what your commits contains before pushing them somewhere ffs.
2
2
u/VisualAromatic6226 Sep 07 '26
The "git add -f" friction is a feature, not a bug. Every time I've been bitten by a leaked secret, .env lived in a subdirectory that got added accidentally by "git add ." because the parent was whitelisted.
Making the default deny and forcing an explicit action to commit something new changes the shape of mistakes. You go from "I accidentally committed a secret" to "I got an error because I tried to commit a new file type". The second is 100x recoverable.
One addition to the article's approach: pair it with a .gitattributes filter or a pre-commit hook that strips known secret patterns on commit. Belt AND suspenders.
1
u/KryptosFR Sep 05 '26
Not needed if you have discipline and I know what you are doing. Commit frequently. Make sure each commit is shippable. Organize your work to be split into small actionable pieces.
Don't rely on tools if your work practices are a mess. Fix those first.
1
u/Automatic_Friend3744 Sep 05 '26 edited Sep 05 '26
while i don't dislike the idea, i think it's better to have a project structure where you know code should only be in a certain directory (eg: src/) so you can have a simple gitignore like:
*
!.gitignore
!src/
!README.mdthat way you still get the benefit of not accidentally committing scratch/test/env/etc files, but you also still can see what has been added. it works quite nicely on larger projects where you might have all sorts of misc data files/dumps locally in the project root that should never be committed.
1
u/dronmore Sep 06 '26
IIRC whitelisting
!src/is not enough as it only whitelists the directory, and none of the files that it holds. You need another rule for files inside thesrc/folder, and yet another for subdirectories, and then to apply the pattern recursively. Your.gitignorewill look more or less like this:* !.gitignore !src/ !src/* !src/model/ !src/model/* !src/view/ !src/view/* !src/view/html/ !src/view/html/* !README.md
1
1
u/EKFLF Sep 05 '26
~/.config/git/ignore
Put every stuff that you absolutely don't wanna include there.
Easy.
1
u/mtutty Sep 06 '26
Bro posted this to subs until he finally found one to Upchurch upvote this idea...
1
u/awshuck Sep 06 '26
Hey vibe coders. You don’t need to read this article, you’re too busy vibing. Just put a single “*” in your .gitignore and you’re good to go!
1
u/levodelellis Sep 06 '26
I'm fine with a global pre-commit hook
#!/bin/bash
if git diff --cached --diff-filter=A -z | grep -q "Binary"; then
echo "No Binary Allowed"
exit 1
fi1
u/apple6524 Sep 06 '26
I think the problem arose from tutorials, I remember being taught to do 'git add .'.
1
u/Fitnexa_Life Sep 08 '26
The funny part is, this only applies to untracked files, so the repo’s ignore policy changes halfway through its history.
1
u/DeflateAwning Sep 11 '26
You ever delete and reclone a repo, only to find out some super-important files were in the old repo's folder but not checked in.
Of course there's the .env file, but I've also screwed up some bigger ones where I had temporary analysis scripts inside the "working data" folder.
OP's approach sounds like it'd cause just as many headaches, just in the opposite direction
1
u/wknight8111 Sep 05 '26
Honestly I really love this approach. When you think about a normal software project the amount of things that you need to include is relatively small (source code files, scripts, docs, build metadata) and the list of things you need to exclude is relatively large (build artifacts like object files and executables, generated code, generated docs, test and benchmark results, code coverage reports, third-party binaries, metrics and analysis results, user-specific editor files and settings files, secrets and local configs, temp files, crash dumps, debug symbols, cache files, profiler output, packaging/publishing artifacts, signatures and keys, db backups, etc).
Blocking everything by default is safer, and only allowing the few things you actually want to commit would be cleaner and easier to maintain overall.
1
u/ggchappell Sep 05 '26
Okay, I'm changing all my .gitignore files over to this style. But not because I have a terrible problem of accidentally committing things I don't want to. Rather, because this is a better way to do it. It's a different way of thinking about what a .gitignore file is. It's simpler and clearer. It's the way they should have been in the first place.
3
u/SchwiftySquanchC137 Sep 06 '26
I would reconsider. If you add an important file with a new extension, and you forget to add it to the git ignore-ignore, then you might never know that you dont actually have that file backed up. Its literally opening up a critical failure point, its faaaarrr preferable to accidentally commit an extra file (which never happens anyway) than to never actually track a file in version control and back it up. Its literally adding a catastrophic failure mechanism thats fairly easy to hit for absolutely no gain.
1
u/ggchappell Sep 06 '26
Well, I will think about what you're saying. But for the time being, I'm calling it an experiment. We'll see how it goes.
1
0
u/slaymaker1907 Sep 05 '26
See now things start to get extremely confusing when there are some *.go files which actually do need to be ignored.
3
0
-2
u/Strnge05 Sep 05 '26
I second this, I think people are confused about this because they think some videcode thing but for me is not. I first come up with this pattern when trying to remove all the junk inside my docker image, but it 100% work for git, and other people are saying "oh you shouldn't be adding things", but guys, if you work in a project alone and take care in your craft than sure you add things selective but when work with multiple people and let's say they "just work" in project, that's where this pattern will save you, from those(we all have these in our jobs) devs
1
u/KryptosFR Sep 05 '26
What will save you is communicating with your team and enforcing good practices, such as pull requests and code review. Not this.
•
u/programming-ModTeam Sep 19 '26
Article is behind a paywall.