You can't use a worktree without write access to the shared object database. You can use worktrees, or you can containerize your agents, but you can't do both.
These pages do look good. But they all just look the same. And I'm getting bored of them.
I open such a page and I immediately know it was Claude that produced it (probably end-to-end). Not that there's anything wrong with that, but it lacks soul… and that makes me kind of sad.
Even the newest models, like GPT 5.5, only deliver what I want nine out of ten times. If I didn't catch the remaining 10% of misguided garbage by manually reviewing every change, it would add up really quickly.
I never look at code. It used to be that it quickly became unmaintainable spaghetti where the agent struggled to make any change at all, but in the past year (and with a three step plan/develop/review workflow), the quality is so good that I basically just don't look at the code any more.
It definitely has fewer bugs than a senior developer, but it really hinges on getting the plan right. 20 minutes of planning and 20 of implementation sounds about right for my workflow as well, just make sure you have GPT as a reviewer. It's very nitpicky and finds lots of bugs.
I'm starting to agree with you; I found the plan/develop/review workflow to work quite well, but I'm not at the point of not looking at the code at all yet.
I guess you actually review and actively participate in making the plan, you just don't review the code afterwards?
Could you share some more details on the specifics of your workflow? (What models/harnesses? do you use the same or different context windows? How exactly do you run the review, and how do you pass along and act upon the information from the review?) Also, how big are the changes you usually implement with one plan/develop/review cycle?
The changes aren't usually very big, basically what you'd put in one ticket. If I need to make large changes, I do them in self-contained stages, if that's possible, otherwise I will tell the LLM to add specific tests in the plan, and I will test thoroughly after.
First, that this is challenging to scale across large orgs. Even if your plans produce high quality code, that isn’t true for everyone. I’m definitely struggling with slop code being collectively mailed to me for review my our 1,000 engineers that were told to use their AI subscription all at once.
I feel like we should be taking “prompt engineering” more seriously. And when people mail me code to review, it should also include the agentic workflow and plan. So that when code isn’t up to quality, and can have a discussion about the prompts used to generate it.
My second thought is related to your senior engineer comment. This isn’t surprising, because in most engineering orgs, seniority is completely unrelated to code quality. In fact, many orgs incentive the opposite: “senior” devs that push out buggy code quickly and push accountability downhill to the junior devs.
I'm so curious to see how other people prompt but literally no one I work with will share it. They might share plans, but they never show the conversation, which is the most crucial part.
Judging by how they struggle to communicate generally, I can't imagine their prompts are doing much heavy lifting.
Eh, everything is challenging to scale across large orgs. Even before LLMs, the code was a huge ball of spaghetti that barely held together. Now we just get there faster.
About senior engineers, I guess that depends on the org you have experience with. My experience doesn't match yours.
20 minutes planning, 20 minutes coding, 200 minutes review and refactor (includes going for a walk and thinking about the problem deeply).
I know a lot of engineers who skip the last part. They're over confident in their original plan. They're over confident the agent actually fulfilled the plan.
You aren't treating this as a question of ROI. Is it worth spending 5x as much to make sure the plan was OK and implemented well? Or is it actually OK if we discover the bug during testing?
The answer won't be the same for all software, but you're assuming it will be.
I've been doing stacked PRs for ~2 years now. Thus, I don't quite see the need for this CLI. Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-absorb[2] and the heavy-lifting is taken care of.
My biggest gripe with GitHub when working with stacks – and something that's not clarified in these docs – is whether fast-forward merges are possible. Its "Merge with rebase" button always rewrites the commit. They do mention that the stack needs to be rebased in order to merge it. My workaround has been `git merge --ff-only top-branch-of-stack` to merge the entire stack locally into main (or anything in between actually) and then push. GitHub neatly recognizes that each PR in the stack is now in main and marks them all as merged. If there are subsequent PRs that weren't merged it updates the base branch.
Having said that, it's great to see GitHub getting a proper UI for this. It's also great that it understands the intent that branch B that goes on top of branch A is a stack and thus CI runs against. I just hope that it's not mandatory to use their CLI in order to create stacks. They do cover this briefly in the FAQ[3], but it might be necessary to use `gh stack init --adopt branch-a branch-b branch-c`. On the other hand, if that removes the need to manually create the N PRs for my stack, that's nice.
> Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-absorb[2] and the heavy-lifting is taken care of.
...or you don't bother with all that and simply do:
Not at all. One of the tricks of using AI is context management and managing the Git history yourself can be a big part of that. If the AI has a stupid idea and implements it, even when you tell it, “that was a stupid idea, don’t do that, change it back”, the history could persist and the stupid idea will poison the context window every time an agent reads the commit history. It’s even worse if you had the stupid idea!
Also, my current workflow actually has hooks to block agents from creating or changing commits. I know at some point this will be a limit to scaling, but I think that will result in me spending more rather than less time in git.
The use of init.defaultBranch here is really problematic, because different repositories may use a different name for their default, and this is a global (your home directory scope) setting you have to pre-set.
I have an alias I use called git default which works like this:
default = !git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'
then it becomes
..."$(git default)"...
This figures out the actual default from the origin.
I work at a company that was born and grew during the master->main transition. As a result, we have a 50/50 split of main and master.
No matter what you think about the reason for the transition, any reasonable person must admit that this was a stupid, user hostile, and needlessly complexifying change.
I am a trainer at my company. I literally teach git. And: I have no words.
Every time I decide to NOT explain to a new engineer why it's that way and say, "just learn that some are master, newer ones are main, there's no way to be sure" a little piece of me dies inside.
No, actually, zero people 'must admit' that it was a stupid, user hostile and needlessly complexifying change.
I would say any reasonable person would have to agree that a company which didn't bother to set a standard for new repos once there are multiple common options is stupid, user hostile and needlessly complexifying. And if the company does have a standard for new repos, but for some reason you don't explain that to new engineers....
There was only a single standard before, so there was no reason why a company should make any company specific standard. The need for companies to make a standard only exists, since the master to main change, because now there are two standards.
Except git init still creates branches named master without configuration (although with a warning), which will only change in 3.0 for obvious reasons, and tons of people (including me) still use master, and old projects don't just vanish.
Why does your company not migrate to one standard? Github has this functionality built in, and it's also easy enough to do with just git.
I'm personally a huge fan of the master-> main changejus5t because main is shorter to type. Might be a small win, but I checkout projects' main branches a lot.
It's extremely obvious that "main" is more ergonomic. It's sad that we're so resistant to change (regardless of how valid you think the initial trigger was)
I love the arguments where you tell me what I “must admit”.
I simply don’t, therefore your entire point is meaningless.
I’m sorry that something so inconsequential irked you so much. Maybe you need to read a book about git if this stumped you bad enough to want to voice your upset about it years later?
I’d consider yourself lucky that everything else is going so well that this is what’s occupying you.
I have a global setting for that. Whenever I work in a repo that deviates from that I override it locally. I have a few other aliases that rely on the default branch, such as “switch to the default branch”. So I usually notice it quite quickly when the value is off in a particular repo.
I'm of the opinion that Git hooks are personal. That's why they're not part of the source code itself. I make extensive use of hooks, but they're tailored to my needs.
Note that you can skip hooks by passing the --no-verify flag to subcommands. Comes in handy when they're slow and you know that you've just fixed the wrong formatting that the previous invocation of your pre-commit hook complained about.
Nice, I use finicky as well, but now and again I have to change a rule or even add a new one. pisses me right off. Anyway thank you for sharing your dotfiles.
> Using commit log diffs as changelogs is a bad idea: they're full of noise. Things like merge commits, commits with obscure titles, documentation changes, etc.
> The purpose of a commit is to document a step in the evolution of the source code. Some projects clean up commits, some don't.
> The purpose of a changelog entry is to document the noteworthy difference, often across multiple commits, to communicate them clearly to end users.
> they're full of noise. Things like merge commits
From another angle, merge commits can also be a solution to the problem. `git merge --no-ff --edit` can be a great way to summarize an entire branch of commits. Most PR tools will give you an easy way to create those kind of merge commits. Don't settle for the default "merge branch x into y", create a meaningful title and fill in details/summary of what happened in the branch. With traversal tools like git log --first-parent you can see a high level of just your merge commits with the gnarly details of whatever steps led up to the merge commit itself.
I've certainly seen good projects where `git log --first-parent` was always a useful first pass changelog (no matter how "clean" the rest of commits were or were not). Probably still not a changelog you should send as a document to end users (because still written from a development standpoint rather than a user standpoint), but a good place to start writing the end user documentation.
Me too, but some tools combine the best of both worlds. In my team we use commitizen [1] which drinks both from keepachangelog and conventional commits and we are quite pleased with our changelogs so far.
[1]: https://git-scm.com/docs/git-worktree