> I made changes to my dependency lists in the same code where Claude ran npm update.

...but was it in the same commit? Two "update lockfile" commits, one yours and one Claude's should have made this obvious, no?

Here's another useful rule of thumb: never mix your changes with the agent's changes. Agent always starts with a clean repository (no pending, uncommited human changes). You always start with with a clean repository (no pending, uncommited agent changes).

Personally I have this in my `AGENTS.md`:

    ## Commit early, commit often
    You are allowed and encouraged to produce small, self-contained commits.
    Never `git push`; I will always review and rebase the full history and do the push myself.
    Commit messages should be *short* and on-point. They're there for *me* to review your work, and *not* a public historical artifact.

So my workflow is usually this: start agent with a clean repository, tell it to do a thing, it works in the background, then once it's finished I come back, review, rewrite and clean up half of what it wrote, then maybe iterate some more with it, and finally do an interactive git rebase to get a clean commit history.

▲ DanielHB 19 hours ago | parent [-]

I don't let claude make commits for me, every commit is my own. I check the diffs before commiting.

> never mix your changes with the agent's changes

yeah, but if you don't want to lose your existing context sometimes you have to. When I do, I tell claude to check the diff on the files I changed, which is quite annoying to be honest. But still easier than telling claude to do _very specific line-change_ on file X.

▲

kouteiheika 19 hours ago | parent [-]

> yeah, but if you don't want to lose your existing context sometimes you have to

Sorry, I'm not sure I follow. What do you mean by "lose your existing context"? Can't you just... commit in turns? It's not like you're editing files while your agent's also editing in parallel, right?

Again, the trick is to treat the commits as throwaway checkpoints/packets of work. They don't need to be pretty, nor need to make sense. The point where you clean that mess up is when you're done and you're doing an interactive rebase at the end. At least that's how I work.

▲

DanielHB 18 hours ago | parent [-]

Ah okay, I thought you meant to fully close the session before you make any manual changes.

In my company we use graphite and stacked PRs so it is highly encouraged to keep one commit per PR, so I am constantly ammending my commits.

▲

kouteiheika 16 hours ago | parent [-]

> In my company we use graphite and stacked PRs so it is highly encouraged to keep one commit per PR, so I am constantly ammending my commits.

So this makes it even simpler for you. Then you don't have to care at all about keeping your commits clean (as in: you don't have to keep them organized enough to be able to reshuffle them into a nice set of multiple commits later on).

Just commit whatever, and then just do `git rebase -i` interactive rebase at the end to squash them. You don't have to keep amending the same commit over and over again!

	▲	DanielHB 4 hours ago \| parent [-]
		Graphite kinda does that automatically with its "gt modify" command. However it keeps the history internally in your PR, but that history doesn't end up in your main branch. Once you merge the PR it looks like a single commit in the main branch history (or a single commit per PR in the stack). It is a bit unfortunate but when using Graphite it is usually better to completely avoid any raw git commands that modify history at all.