r/git

Hi there,

I am still working on my Codeberg review but since Codeberg deserves much more attention, I thought I could publish this instead first. It's a really great alternative for the AI dumpster fire that GitHub has become.

I enjoy using it.

Did any of you switch to Codeberg yet? Or still in GitHub?

I've been using a bare repo with GIT_DIR=$HOME/.dotfiles.git/ GIT_WORK_TREE=$HOME git "$@", showUntrackedFiles = no, and host-specific branches rebased on main for common and host-specific changes to dotfiles. Works decently, but some quirks I have: 1) I can't git add dotfiles with relative paths like I can in a normal repo; 2) I use Neovim and certain git-related plugins don't support this whole $HOME worktree bare repo thing; and 3) it's not immediately obvious when looking at my $HOME which files are not important to me (i.e. those not tracked, even if I can ls-tree to find only those tracked).

I remember trying stow a long time ago when I just started out Linux--if I recall correctly I didn't like that $HOME was littered with symlinks for some reason.

I hesitant to try these numerous dotfiles utilities that are opinionated wrappers around git.

• Which solution have you found works best? I prefer least complexity and cognitive overhead. I'm actually thinking perhaps stow was the right solution and that symlinks are not an issue. I like that it lets git do its thing and stow does its thing, the "unix way." I think I was put off by the fact that in an app I used, it contained a config file where it actually didn't work for the app if I symlinked it for some reason (it would overwrite the file but only if it was a symlink--not sure why). Curious if there are any gotchas like this regarding heavy use of symlinks.

• I want to manage system config files as well, but there is the added nuisance of maintaining and/or tracking ownership and permissions. I heard of etckeeper but from what I've read it doesn't work the same if you try to track files outside of /etc (no surprise) like some in /usr and /boot (bootloader config). I'm not sure if overkill to look to learn/use Ansible for this but it seems like the most complete solution (store system config repo where ever, when config files are changed, run Ansible to copy them over to where they belong and set the intended ownership/permissions.

I know some people feel git cli is the only complete solution, but the shell feels awkward when a quick couple of keybindings can do the same for common tasks you would be doing 95% of the time (finding the hash and copy/pasting is annoying--I can imagine there are fzf wrappers for this but after hearing about Emacs's magit, Vim's Fugitive, lazygit, etc. I just feel like a UI with at least keyboard-driven workflow or integration with an editor directly cannot be beat.

Curious all the plugins/utilities you guys use to cover all aspects of using git from typical tracking to diff, merging, worktrees, etc. I know this is opinionated, especially because no utility may necessarily do everything better and from that perspective, a utility that might do 90% of the things well could lose out to a combo of utilities that do each do less but complement well to be more than the sum of their parts.

Would just like to get some ideas because I don't want to e.g. try Fugitive with the wrong expectations and spend months developing custom keymaps only to find maybe e.g. Neogit, lazygit, gitsigns.nvim, diffview.nvim, etc. might work better. Of course, git cli is still the fallback if necessary.

Hello Git gurus. Me and my team are in bit of a pickle with keeping our current feature/release branch up to date with what's happening on our master branch. To give some background, I'm working at a semi-large international company where we have devs in Europe, Asia, and South America. Currently, me and my team have been working on a feature branch for a while, and it's planned to live until November this year. We are around 10 devs all contributing with squashed PRs to our feature branch. However, our other international teams are all contributing with squashed PRs to the master branch, where those PRs are a mix of deeply embedded systems, new features for other clients, or refactors of old systems.

The first few months of our project we rebased our feature branch against master every week or so, and that was mostly fine until we were around 100 squashed PRs ahead of master. Then it started to take developers full weeks just to rebase our feature branch, which was completely unsustainable. Since then we have switched to instead merge master into our feature branch every week, taking in all the new changes. That worked well at the start, but now we are several hundreds of PRs ahead of master and it's again starting to take several days to merge master into our feature branch.

From my point of view, our troubles stem from a combination of these issues:

• Our PRs merged months ago relied on the state of master then, since then master has changed, so the old PRs are in a sense invalid. This means that when updating our feature branch we have to go in and fix old PRs, which only adds to the ever growing problem.
• We are refactoring old systems to fit our new features, and that does not always go into master. Sometimes this is because the refactor is extremely invasive to long-living systems, but crucial for our project. So in that case those refactors have no purpose living in master as any faulty changes may impact our clients' satisfaction rates. Other times they don't get merged to master because of human error.
• Our feature branch is progressing at a normal pace, a couple of PRs merged per day. However, the master branch is growing at maybe 50 PRs per day. When I say PRs, it's anywhere from 1 to 2000 lines of code changed per pull request. So at worst, a weekly merge of master could involve tens of thousands of lines only coming from master. I don't think it's a very normal amount of code to handle each rebase or merge.

So I've been thinking for a while now, me and my team can't possibly be the only ones with a long-living project like this. I'm wondering how other teams in similar situations have tackled this problem.

Our discussions so far around combating this problem has included things like:

• We merge everything to master but hide it behind compilation flags or macros (this is an embedded C++ project)
  • This is not feasible due to business secrecy. Regulatory bodies (and sometimes clients) regularly decompile our software, and there can be no traces of my team's project what so ever. Merging everything to master feels like us begging to fail the project by leaking information to clients or competitors.
• We suggest to other teams that invasive changes that are merged to master are also merged to our feature branch.
  • This feels like a huge overhead that we are bringing to other teams, which have different priorities, clients, and funding/budgets. Because of that this also feels infeasible.
• We start doing nightly merges of master into our feature branch. Whenever a merge fails, one developer has to go and either discard the merge completely, or patch it up so that we can update our feature branch.
  • This makes the problem more granular, but doesn't combat it. Instead of a dev wasting 3 consecutive days of work, they might waste 4 hours every day of the week. So in a sense this would only automate the "easy" part, which isn't very helpful.

So I'm wondering if any other large, cross-team codebase has found a better way to work like this with long-living projects? Or have me and my team just found ourselves in a very weird position? Thanks in advance.

Currently I use Kdiff3 to resolve conflicts.

However, there are times where Kdiff3 incorrectly auto resolve merge conflicts incorrectly. As a result, I have to look through all changes and verify them.

Is there an AI tool that is smart at resolving conflicts or where you can tell it what you prefer to happen, even if the algo/date/time of the commits don't make sense?

maybe this is just what happens once projects get bigger but lately i feel like half my time disappears into CI nonsense instead of actual development. at first github actions felt great because everything was in one place. then over time the workflows got bigger, more runners, more marketplace actions, more deployment logic, more review automation, more weird edge cases nobody documents properly. now every small issue somehow turns into 2 hours of debugging YAML and permissions
i started trying other setups a while back mostly because i got tired of patching around the same problems over and over. self hosted runners helped in some ways but also created their own headaches. eventually ended up moving a decent chunk of workflows into other alternatives like tenki and gitea instead because i wanted something that didnt constantly feel held together by random marketplace repos and fragile configs. still using github for repos obviously but i definitely understand now why people stop wanting their entire workflow tied to one platform after a while

Turns out: very visible. Yesterday's scan found 185 out of 185 engagers on a single repo were bots. Not 90%. Not "mostly suspicious". Every single one. The repo had zero legitimate stars.

What I built

phantomstars is a Python tool that runs daily via GitHub Actions (free, no servers):

1. Scrapes GitHub Trending and searches for repos created in the last 7 days with sudden star spikes
2. Pulls star and fork events from the last 24 hours per repo
3. Bulk-fetches every engager's profile via the GraphQL API (account creation date, follower counts, repo history)
4. Scores each account on a weighted model: account age (35%), profile completeness (30%), repo patterns (25%), activity history (10%)
5. Detects coordinated campaigns using timestamp clustering and union-find: groups of 4+ suspicious accounts that engaged within a 3-hour window
6. Files an issue directly on the targeted repo so the maintainer knows what's happening

Campaign IDs are deterministic SHA-256 fingerprints of the sorted member set, so the same group of bots gets the same ID across runs. You can track a farm across multiple days even as individual accounts get suspended.

What the pattern actually looks like

It's remarkably consistent. A fake engagement campaign in the raw data:

• 40-200 accounts, all created within the same 1-2 week window
• Zero original repositories, or only forks they never touched
• No bio, no location, no followers, no following
• All of them starring the same repo within a 90-minute window
• The target repo usually has a name implying it's a tool, hack, executor, or generator

Today's scan: 53 active campaigns across 3,560 accounts profiled. 798 classified as likely_fake. The repos being targeted are mostly low-quality AI tools and "executor" software that needs manufactured credibility fast.

Notifying the affected repo

When a repo hits a 40%+ fake engagement ratio or a campaign is detected, phantomstars opens an issue on that repo with the full suspect table: account logins, creation dates, composite scores, campaign membership. The maintainer sees it in their own issue tracker without having to find this project first.

Worth noting: a lot of these repos have issues disabled, which is a red flag on its own. Those get skipped silently.

Why I built this

Stars are how developers decide what to evaluate, what to depend on, what to recommend. When that signal is bought, it affects real decisions downstream. This started as curiosity about how measurable the problem was. The answer was more measurable than I expected.

It's part of broader research into AI slop distribution at JS Labs: https://labs.jamessawyer.co.uk/ai-slop-intelligence-dashboards/

The fake engagement problem and the AI content quality problem are really the same problem. Fake stars are the distribution layer that gets garbage in front of real users.

All open source. The data is append-only JSONL committed back to the repo after every run, queryable with jq.

Repo: https://github.com/tg12/phantomstars

Findings are probabilistic, false positives exist, the README explains the full scoring model. If your account shows up and you're a real person, there's a false positive process.

Questions welcome on the detection approach, GraphQL batching, or campaign ID stability.

I kept watching people (and myself) panic after a bad reset or rebase, even though the commmits were almost always still sitting in the reflog. So i made a small tool that scans the reflog and dangling objects, guesses what went wrong, and walks you through fixing it. It makes a backup branch before doing anything destructive, and after each fix it tells you what command it ran.

It's an early beta so right now it handles lost commits, deleted branches, detached HEAD, dropped stashes, and being stuck mid-merge/rebase. I'd genuinely like to know what other recovery cases are worth adding. So uhhh you can let me know in the Issues tab if you have ideas 😄

https://github.com/septcoco/git-unfuck

demo <3

Hi r/git 👋

I've been building a modern cross-platform Git client called Enjoy Git.

Built with Electron, Vue 3, and TypeScript.

Supported platforms:

• Windows 10/11
• macOS 10.15+
• Linux (.deb / .rpm)
• x64 + arm64

Supported languages:

• English
• 简体中文
• 繁體中文

Some features:

• Clean three-column UI
• Line-level staging
• Commit graph visualization
• Conflict resolution
• AI commit generation ( open ai & deepseek )

Quick demo:

https://i.redd.it/egyomf1t2i2h1.gif

Would love to hear feedback from Git users 🙂

GitHub:
https://github.com/huangcs427/enjoy-git-release/releases/tag/v1.0.0

I work on spreadsheet infrastructure, and I’ve been thinking a lot about why agents took off so quickly in programming — but feel much slower to land in spreadsheet-heavy teams.

I don’t think the difference is model capability.

And I don’t think it’s because non-technical teams are resistant to AI.

In fact, when ChatGPT first arrived, teams like finance, HR, sales, operations, and marketing adopted it incredibly fast for writing, summarization, planning, research, and analysis.

The appetite was obviously there.

So why does the “agent era” still feel so much further ahead in programming?

My current belief is: programming already had Git.

Not just Git as a tool, but Git as an operating environment for collaboration between humans and machines.

I work on an open-source spreadsheet project, so I spend a lot of time looking at how companies actually use spreadsheets.

Not toy spreadsheets.

Real operational workbooks:

forecast models, revenue reports, pricing sheets, headcount plans, commission trackers, sales ops systems, finance templates.

These files already contain production logic.

And agents are becoming surprisingly capable at operating them.

They can write formulas.

Update tables.

Transform data.

Build charts.

Automate workflows.

Technically, a lot of the capability is already here.

But the moment agents start touching important spreadsheet logic, trust breaks down.

Because spreadsheets still behave like documents, even when they function like software systems.

In programming, an agent can modify a codebase and humans still remain in control.

You can inspect the diff.

Review the change.

Run tests.

Approve it.

Revert it later.

Trace the history.

That infrastructure changes the emotional experience completely.

Without it, agents feel risky.

With it, they feel usable.

Spreadsheet-heavy teams have the same underlying needs.

If an agent updates a forecast workbook, people still need to understand:

• what changed
• which formulas were affected
• whether calculations refreshed correctly
• whether downstream metrics moved unexpectedly
• whether charts or formatting broke
• who approved the change
• how to restore the previous version

These are fundamentally Git-style questions.

The problem is that spreadsheets contain production logic, but most spreadsheet workflows still lack production-grade collaboration infrastructure.

So my current belief is that spreadsheet agents don’t just need better prompts or larger context windows.

They need a Git-style runtime:

diffs, reviews, approvals, rollback, traceability, and structured collaboration between humans and agents.

That feels like the missing layer.

We’ve been exploring this direction ourselves and released an early runtime for spreadsheet agents today.

Still very early.

Could be wrong.

But I increasingly think agents will only become truly usable in operational workflows once humans can collaborate with them safely — not just prompt them.

Curious how others see this.

If you’ve tried bringing agents into finance, sales ops, HR, planning, or spreadsheet-heavy workflows, what actually blocked adoption?

I have some web framework boilerplate code, login, auth, home, about, etc. and I want to base a bunch of new web apps on that repo...but also push new commits to the boilerplate repo and eventually pull those changes into all the new web apps I've written.

I'm thinking I could create a repo, 'web_base', and when I create a new web app, I clone the latest 'web_base' repo, init a new repo around it, and start committing new custom web app code.

Is there an easier way? Some feature of git or maybe github that I'm not yet aware of? I feel like I'm trying to do this the hard way. Also, I still havent wrapped my head around how best to merge new commits made to 'web_base', say security fixes, so that all the existing web app repos now have the latest boilerplate commits, too.