Had a repo where raw camera photos (7-10MB each) were committed directly, and deleted files were still living in git's object database. Wrote up how I diagnosed it with git rev-list --objects, cleaned history with git filter-repo, and why I chose image compression over Git LFS for this case. Includes a comparison table of when LFS actually makes sense vs when you should just compress your assets.
I have never understood the advantage of git vs. SVN. Git is the new way and so I am not opposed to it, but I have never been clear on why it's advantageous to have a local repo. Perhaps it's a bad habit on my part that I don't commit until I am ready to push to the remote repo because that's how it's done in svn and cvs, but if that's the way I use it, does git really buy me anything? As mentioned, I am not saying we shouldn't use git or that I am going back to svn, but I don't know why everyone moved away from it in the first place.
I'm a complete beginner to Git and coding in general and working on a game jam with some friends - each time I try and push my branch to the repository, Git asks for my username and password, so I enter my username, contf. However, it then asks my to enter my password for the GitHub account [email protected], which is not my account. My username is contf, but the associated email is different. I know this is a very beginner issue, but does anyone have any tips to point me to a way to correct this?
I've been learning HTML, CSS, JS for about a year now so I'm almost completely new to the game. I got into this through the theodinproject.com and I've been doing pretty ok so far. TOP has dedicated a whole chapter about setting up and using Git and Github. I did it, tried it, it worked and then I went on and forgot about it.
So here I am about half a year later, sitting and trying to understand how the fuck I just managed to oblitirate 800+ lines of code somewhere between the commands. I honestly have no idea how I did it and where it went. After I realized what I've done and that there's no coming back I proceeded to rage quit and deleted the whole repo. I know it's dumb and I regret it now if of course but sometimes I just can't help it.
Anyway, I'm about to rewrite those lines I lost and before I do it, I would be forever grateful If someone could help me understand how Git works. Like seriously, I need someone to guide me through the basics again, to point out common mistakes and tell me how to avoid them. Kindergarden type of shit. I want to understand what I'm doing and how to do it properly.
So if there's anyone who is willing to donate a few minutes to help out a beginner in distress, DM me please.
Hello! I've got a 'under the hood' type of question about git. Hope I make sense and that its not too stupid of a question. So when working with git theres these commands that do different type of actions, like git add, git commit and so on. Are these commands using bash underneath, or how does it work? Is git a shell in itself?
I’m working on a project with a team, and I’m the junior developer among them. In our project, there are around 30 branches, which feels quite messy to me. I don’t really like disorganized setups—I prefer things to be minimal and well-structured. Personally, I think there should be fewer branches and a cleaner working tree. I’d love to hear your thoughts on this.
Type any words you like, your name, username, a phrase, a tagline, literally whatever , and it generates it as a contribution-graph-style visual that you can download.
Thought it could be a nice little detail for developer portfolios, personal websites, etc.
Made it for fun. Curious to see what people make with it.
I often see developers (even experienced ones) mix up HEAD with “head branches.”
I wrote a short, example-driven post that breaks down what HEAD actually points to, what "heads" really mean in Git internals, and why “detached HEAD” isn’t an error -> just a state.
It’s a 2-minute read, aimed at developers who want to finally make sense of Git’s terminology:
My team at work is switching to GIT and none of use have any experience with it. In the past, I've used Team Foundation Services and it made sense... files are saved on a server, check it out to make edits and check it in when done. Yeah, it was limited to a single user editing a file at a time. My problem is using GIT via CIL... 1) I have dyslexia (and am also bad at typos). 2) I don't even know what commands I need to type. 3) When running into errors, I have zero clue what to do, and end up trashing my repo and starting over.
Is there an easier way to learn the ins and outs of GIT w/o so much trial and error? I know it would be as popular as it is if it were a POS, but I can't help but hate it.
I wrote a small tool for a problem I kept hitting and I'd like people who know Git well to poke at the design.
The problem: files that belong to me, not the project, but have to live in the working tree. .env.local, notes, scratch scripts, my own agent-instructions file. .git/info/exclude hides them and does nothing else. The dotfiles-style bare repo over the project versions them, but you maintain the exclude entries by hand, stash -u from that repo's point of view stashes the entire project, and nothing stops you pushing the private repo to the project's remote.
How it works:git dupe init creates an ordinary repository at .git/dupe with a relative core.worktree (../..), so moving the checkout keeps it attached, and status.showUntrackedFiles=no plus advice.statusHints=false so Git's own status and commit template never enumerate the project or name a plain git command. git dupe <command> runs Git with that GIT_DIR, with the object-directory environment overrides stripped so the two repos share no objects. Every path the private repo tracks, plus a .gitdupe list of hidden directories, is written into a # BEGIN git-dupe … # END git-dupe block in .git/info/exclude and re-verified after every command. If a ! rule in a tracked .gitignore outranks the exclude and exposes a path, the command names the path and the rule.
Three commands change meaning because the tree is shared: status and add are confined to the hidden paths (otherwise the whole project is untracked), and clean cleans the project while sparing them. Refused, one fatal: line, exit 128: stash -u/-a; any push/pull/fetch/remote/clone whose URL is the project's own repository or one of its remotes; add on a path the project tracks. git dupe git <words> runs Git with no guards for when you mean it. git dupe detach removes the private repo and the exclude block and leaves every file on disk; without --force it refuses while anything is uncommitted or not on a remote. Of its own accord the tool writes only .git/dupe, that block (and .git/info if missing) and .gitdupe, and the only process it starts is git.
Where the project's Git can still reach a hidden path, as far as I've mapped it:git clean -x deletes them (ignored files, as far as Git knows), git stash -a stashes them, git add -f stages them, and anything that writes the index from a tree or a patch rather than the ignore walk can stage one too: a merge, cherry-pick or rebase of a commit that adds a file at that path, apply --index, am, update-index --add. When that happens the path is tracked by both repos; it stays hidden, and every following git-dupe command warns about it until one side lets go. I chose to document all of that rather than hook or wrap plain git. Verified by hand: the project's gc --prune=now and prune don't touch .git/dupe (separate object store), and public stash -u leaves private files alone. The suite also has a scale scenario: six commands among 100,000 tracked files, each under a second, with Git run a fixed number of times.
Limits: Linux only. Git 2.43 or newer, below 3.0 (CI runs the suite under 2.43 and 2.56; the full run under every minor through 2.56 happens before a release). Linked worktrees refused for now. No encryption; the remote you push to holds the files in plaintext.
Prior art: vcsh and the bare-repo dotfiles trick (same mechanism; neither knows about a host repo's exclude or remotes), multigit (N overlapped repos, no public/private asymmetry), and Layer from a Show HN in March (manages exclude plus local snapshots, no remote).
Couple of questions. Is there an index-writing path I've missed above? And for linked worktrees: .git/info/exclude and .git/dupe both already live in the common dir, so one private repo with a per-worktree index (GIT_INDEX_FILE) seems possible. Would you want that, or one private repo per worktree?
Transparency: A majority of the code and tests were written by coding agents under my close supervision. I own every decision in the product specification including the CLI surface and the tradeoffs made and set the rules and flows that the agents worked under. The original principle/intuition that guided me when writing the product specification was to "piggyback" off of native Git as much as possible and to make the CLI surface similar to native Git. Only where it clearly did not make sense to me to do a naive Git passthrough, did I add git-dupe-specific commands/mechanisms/guards).
Edit: After reading some feedback, I realized using `.env.local` in the example might make it seem like git-dupe is made for tracking and pushing sensitive information. It is not. Just like normal git, pushing sensitive information into the remote repo is possible, but this is bad practice. git-dupe was made for my personal use-case of keeping personal notes/agent instructions outside of public-facing repos. As listed in Limits: "No encryption; the remote you push to holds the files in plaintext.", so you are discouraged from pushing things like passwords or other sensitive information even if it is a private repository.
I want to leave any Microsoft affiliated softwares, and I wanted to know if it is easy to switch from github to gitlab. Will I find all github’s functionality in gitlab? (I have an education license so my github account is a pro account)
It’s a terminal Git client written in Rust. The main goal is to make working with Git history feel fast, especially in large repositories where scrolling through commits or waiting for a UI to catch up gets annoying.
The biggest feature is fast graph navigation. You can jump around the commit graph almost instantly, move through branches and history, inspect commits, check diffs, and get a better overview of what actually happened in the repo without leaving the terminal.
It also has reflog support, which is one of the features I’m most excited about. If you’ve ever lost a commit after a reset, rebase, cherry-pick, or detached HEAD situation, Guitar makes it easier to find those commits again and recover them instead of digging through git reflog manually.
I’ve also been building it with huge repositories in mind. History loads incrementally, so you can start using it without waiting for the whole repo to load first. The goal is for it to stay responsive even when the repo has a lot going on.
Some other things it supports: branches, tags, stashes, worktrees, staged and unstaged changes, commit inspection, file diffs, split diff view, configurable keymaps, mouse support, and real Git operations like commit, checkout, fetch, reset, cherry-pick, merge, rebase, stash, and worktree commands.
It’s cross-platform and runs in the terminal, so the idea is to have something lightweight and fast without giving up the useful parts of a proper Git GUI.
It’s still a work in progress, but I think it’s already useful enough to share. I’d love feedback, especially from people who work with large repos, messy histories, rebases, cherry-picks, or reflog recovery.
Two nights ago someone with a large following posted my self-hosted workout tracker (openGym) on X. It took off, and the repo picked up a lot of stars within a couple of hours.
Roughly two hours later, my GitHub account was suspended. No prior notice, no stated reason.
I've never bought, traded or solicited stars or engagement of any kind. My assumption is that the spike tripped an automated inauthentic-engagement filter, and because it happened overnight, the action landed before a human looked at it.
Since I've had to figure most of this out from scratch, here's what I've learned about the process — none of it is documented anywhere obvious:
You can't see your own ticket. While suspended, the support portal is inaccessible. The ticket system runs separately from your account status, so tickets stay valid — but the only way to track or update one is replying to the automated confirmation email you got when you filed it. Check spam.
Appeal and reinstatement are different things. A reinstatement request implies you accept that a violation happened. An appeal disputes that one occurred at all. If you think you were flagged wrongly, make sure you filed the second one — the framing matters.
You have six months to appeal. No reason to panic-file a half-finished case.
Don't create a second account. It's the most common piece of advice people give each other and it consistently makes things worse.
Don't open a second ticket. It splits your history across threads and slows things down rather than speeding them up.
Current status: appeal filed with exact timestamps and a link to the post, so the referrer data on their side should confirm where the traffic came from. Two days in, no reply — which from what I can tell is normal.
Meanwhile the repo is unreachable and third-party re-uploads have already appeared that I don't control and can't vouch for. The mirror I do control, with full history: https://gitea.com/DuarteSantos/openGym
Since GitHub Discussions went down with the account, I set up a Discord for updates and self-hosting questions until it's back: https://discord.gg/e62jY6fwVb
One question for anyone who's been through this: has an inauthentic-engagement flag ever actually been reversed for you, and roughly how long did it take?
