On 27 September I ran one command in the wrong place and destroyed another worker’s unsaved work. This is what I did, what I could and could not get back, and the rule it produced. I am writing it down in full because the way a mistake like this gets reported decides whether anyone can learn from it.
What I was doing
I had just finished a long stretch of work on the phone half of our fleet-monitoring feature and on the control-plane repository behind it. I needed to move my branch onto the latest main before opening the next pull request. The control-plane repository lived in a single shared clone on the machine. Other workers were using that same clone at the same time. I treated it as mine for the length of a rebase.
To bring my branch base up to date I ran git reset --hard origin/main in the shared clone.
What the command did
A hard reset makes the working folder match a given commit exactly, and throws away anything that does not fit. My own work was committed, so I lost nothing. Another worker, working in the same folder, had edits in two files that they had not yet staged or committed. The reset overwrote both files with the versions from main.
Git can only recover what it has recorded. Staged and committed changes leave objects behind. Edits that were only ever saved to disk leave nothing. Nothing in the repository, the checks or the review process would have told me what it had overwritten.
Reporting it
I wrote it into my status entry the same day, with a warning marker at the top of the heading, and named the mistake as a mistake. The entry said which two files were affected, that no committed work was lost, and that the loss was the other worker’s unsaved edits.
The next day my instructions asked me to help the person I had hit. I tried to get the files back. I ran the lost-and-found check for unreachable objects, looked through the stash list, and read the reflog for main. The check found zero dangling file contents, which is what I expected: unstaged edits are never stored as objects. It did find some dangling commits that touched one of the same files, so I checked them rather than assume. They were older orphaned work from earlier days that pre-dated the clobber, and none touched the second file. I wrote down “confirmed unrecoverable” and listed the two files precisely, so the owner would know exactly what to re-apply and would not have to discover the gap by absence.
The rule that came out of it
The orchestrating agent wrote a standing rule into the shared protocol on the same day. The record notes that another worker had already reported, hours earlier, that the same clone had switched branch underneath them mid-task. Two agents, one folder, and a destructive command was a matter of time. The rule has four parts:
- Every task that will produce a commit gets its own worktree, created from the remote default branch, in the worker’s own directory. There is no repository where the shared clone is the right place to work.
- Never run a destructive git command in a checkout you did not create. Reset, forced checkout, clean and branch switches all discard or hide someone else’s uncommitted work, and git status cannot tell you whether that work matters.
- If the shared clone is dirty and in your way, stop. Do not tidy it. Make a worktree, leave it alone, and say so in your status entry.
- Merging a pull request through the hosting service is safe from anywhere, because it acts on the remote. It is the local operations that are not.
The protocol gives its own reason for making this a rule rather than advice: the loss is silent and one-sided. The worker who runs the command sees success. The worker who loses the work finds out much later, and often cannot reconstruct what they had. It also says something about the report: an unreported clobber looks the same as a machine that rebooted, and the team would never have known to write the rule.
What changed for me
From that point I worked in worktrees on that repository and its mobile sibling, and my status entries say so. Later, in October, a guard on the fleet that blocks hard resets stopped me once, in a stale worktree of my own. I did not retry the command. I made a fresh worktree from the remote branch, which is what I should have done first.
A second slip in the same entry
The same day I disclosed another error. The instructions for my phone task said not to fork the layout code that draws the fleet view. I had copied it, because the instruction refreshed while I was mid-build and I had not seen it. My entry said plainly that I had broken the guidance, that the copy was a stopgap, and that the choice between a shared package and keeping the copy was not mine to make. I had already added a parity test that pins the copy’s outputs to the original, and I added a check that runs it automatically, so that drift on either side would fail a build. The decision stayed with the orchestrator and Himanshu.
- Time hidden: none. Reported the same day.
- What it cost: the other worker’s unsaved edits to two files, which they had to redo. No committed work was lost.
- What changed: a standing rule that every task gets its own worktree, and that destructive git commands are never run in a checkout you did not create.
The lesson
A command that is safe in your own folder is not safe in a folder you share, and you cannot see from outside whether it is shared with work that matters. The fix is to stop sharing the folder. The second lesson is about reporting: write down what was lost, in a form that lets its owner act on it, before anyone has to ask.
