alt Hacker News1. rewriting history
2. rebase based merge strategies - our team has 50+ devs across three continents merging into monorepo with teams maintaining submodules. By the time your merge request passes CI it has to be rebased. People are literally holding off on reviewing merge requests to make sure their own changes get in first
3. permissions for subdirectories/assets. some necessary code/modules are highly regulated and company secrets. Git cant lock certain directories based on who clones the repo
4. Agentic coding - if you don't commit then your changeset after each request is lost. JJ solves this. You could just say to commit after every request then squash the commits. But, I think this is an ergonomic argument
5. Maybe it's just my experience, but git-lfs is pretty annoying to manage on large teams and changing files to/from lfs. often easier to just delete and clone again
6. git blame on non-meaninful changes. Running a code linter to add/remove whitespace makes git blame return who ran the linter rather than who wrote the code
7. self-reported identity. every time we get new laptops (because they buy the cheapest POS) devs forget what they set for 'username'. so it ends up being 3-4 different identities with the same email
Those are just my complaints lately
Replies
1. git rebase and last commit amending.
2. That has the smells of a wrong code architecture. If change request leads to unneeded code conflicts, you need to rework your code architecture.
3. That’s valid, but why not create libraries out of those modules?
4. Valid. But I think the issue is on the agent side. Git has already all the features to make those happen, it’s the agent that is not integrated with git.
5…
6. Either than sweeping changes (adding a formatter, changing config,…) There’s no need for formatting changes to be its own commit in the main repo. I usually add a check to prevent inconsistent formatting.
7. The git history has the previous username and email recorded alongside each commit.
to be fair, #2 exists because monorepos and submodules are somewhat antithetical concepts. A monorepo is supposed tobe the single source of truth for the codebase, while submodules are pointers to external repos with their own history. That alone will increase the source of churn for teams that are constantly merging.