Git Is Not Fine

I continue not to understand much of the point of this. I don't recognize the git workflow the author is talking about, and neither do I see the point of stacked PRs. Commits are fine as a unit of isolating work, and rebasing to keep that neat is not difficult.

How many PR's do y'all tend to have in flight at once? I sometimes think being a native (C++) developer makes me have a different take on some of this. Maybe if I was a JS dev making quick changes with 5 PR's a day I'd care more about this.

	▲	bjconlan 3 minutes ago \| parent \| next [-]
		In a corporate codebase which was a monorepo I've found this to be worse... But it's the bed you lay in. I think of about 15-20 developers working on the codebase you would see about 20 prs/day of which only about 1/2 would be reviewed in a timely manner which would lead to pr atrophy over the week. Again this was an "institutionalized agile" shop so de-optimsation was gamed as progress and feedback always "taken into consideration". I don't think this is a unique scenario for larger teams.
	▲	lorecore an hour ago \| parent \| prev \| next [-]
		I totally agree. I've never understood the push back against clean "railroad tracks" (i.e. rebasing instead of merge commits). It's simple, scales nicely and gives you a lot of options. Once you start allowing merge commits in the tree, things can get messy but with a bit of discipline, it elegantly solves every version control use-case I can think of, or have encountered, including at scale.
	▲	squirrellous 11 minutes ago \| parent \| prev [-]
		Stacked PRs is mostly a way to avoid thousand- or tens-of-thousands- LOC branches, which makes each PR meaningfully reviewable. You need a good code review process for it to become useful. It’s very pleasant once you are accustomed to it. I’ve seen successful teams that regularly do reviews of massive PRs and feel this serves them well enough. I suspect it just places a lot more trust on the developers to get the details right so reviewers only look at larger design issues. The language of choice is not relevant. Even before AI, one can accumulate thousands of lines of c++ easily.

▲

vintagedave 3 hours ago | parent | prev | next [-]

I admit the diagrams and struggles the author describes are far past my own usage of git. And like they identify at the end of the article, for truly complex git operations today I use AI. I haven’t rebased manually for a while. Forget rewriting commit messages!

> Companies like Meta have enjoyed in-house systems that run circles around it for almost a decade.

Based on Mercurial… the VCS I enjoyed using.

	▲	miguel_martin an hour ago \| parent [-]
		There is an open source & git compatible version of Meta's VCS: https://sapling-scm.com/

▲

alphabeta3r56 2 hours ago | parent | prev | next [-]

> There is No C

Well yes because git was supposed to be completely distributed. You can design a system which has this feature but then it wouldn't be as distributed as git, making unrelated forks second class citizens. It might still be a good idea for tool to have it but it is not strictly a better/worse scenario.

> Mutability

I think i can mostly agree to this. I do wonder if people never work in a scenario where they are only committing partial state and not complete state. Nevertheless being able to track and not losing uncommitted state is a strict improvement.

> workflows

Aren't worktrees enough here?

▲

karmakaze 3 hours ago | parent | prev [-]

This has pretty pictures but its verbosity and frankly made-up complexity is making me not take it as seriously as I perhaps should.

The way I'd handle rebasing stacked PRs/branches is to rebase the very last one. Then simply `git branch -f a-branch <logical same point on rebased>` for each of the others, done.

I worked on a project that had weekly releases. We had git submodules, and submodules of that, and on rare occasions a 4th repo. I would manually keep those all up to date with rebases pinning each submodule to the logical new points. It all became muscle memory. The lesson I learned is don't use submodules unless you really need to. (All the repos were our own.)

JJ may be great but a stawman isn't going to sell it to me.

Now I can tell an AI to rebase a stack and as long as there weren't any conflicts easily check the results.

Everyone has things that bug them, git isn't one of mine (today :-). Instead I have a custom keyboard layout that no one else uses that makes me feel better, but I don't go around telling everyone they should switch--unless you're curious[0].

[0] https://github.com/qwickly-org/Qwickly