Summary (TL;DR)
If a developer forgets to run mob start before making changes, then runs mob next, Mob creates a local commit.
If they then run mob start to catch up with the latest mob session, Mob force-resets the branch to origin/mob/main and silently discards the local commit.
The work is only recoverable via git reflog.
This is different from a push rejection: the problem is mob start always doing a hard reset.
Environment
Scenario (Step-by-step)
Dev A (correct flow)
mob start
- make changes
mob next # pushes successfully
Remote mob/main moves forward.
Dev B (forgot to run mob start)
- Already on the
mob/main branch
- Starts working without
mob start.
- Makes changes locally.
- Runs
mob next:
- Local commit exists on
mob/main.
- Push get rejected b/c remote advanced — but the commit is still in the local branch.
- Dev B runs
mob start to "catch up":
- Force-reset happens.
- The local commit from
mob next is deleted from the branch and working tree.
- Only recoverable via
git reflog.
Why this is problematic
- The push rejection is not the root cause; it’s just a common trigger.
- The real problem:
mob start always resets the branch, regardless of local commits.
- This makes the workflow fragile, and it’s easy for developers to lose work silently.
Expected behavior
mob start should detect local commits not on the remote and refuse to reset blindly.
Example:
“You have local commits on mob/main not on origin/mob/main. Please pull/rebase/push your changes before running mob start.”
Alternatively, provide an option to rebase local commits instead of overwriting them.
Suggested improvements
1) Safety check before reset
git log origin/mob/main..mob/main
If non-empty → abort mob start with clear instructions.
2) Guidance after failed mob next
When the push fails:
“Your commit exists locally but is not pushed. Run git pull --rebase origin mob/main and then mob next. Do not run mob start before resolving divergence.”
3) Optional rejoin-local mode
Automatically rebase local commits onto origin/mob/main instead of discarding them.
Why this matters
Mob abstracts Git for collaboration. In this case, that abstraction hides a destructive Git operation, leading to silent data loss.
A simple safety check would prevent this from happening in real-world sessions.
Summary (TL;DR)
If a developer forgets to run
mob startbefore making changes, then runsmob next, Mob creates a local commit.If they then run
mob startto catch up with the latest mob session, Mob force-resets the branch toorigin/mob/mainand silently discards the local commit.The work is only recoverable via
git reflog.This is different from a push rejection: the problem is
mob startalways doing a hard reset.Environment
Scenario (Step-by-step)
Dev A (correct flow)
mob startmob next# pushes successfullyRemote
mob/mainmoves forward.Dev B (forgot to run
mob start)mob/mainbranchmob start.mob next:mob/main.mob startto "catch up":mob nextis deleted from the branch and working tree.git reflog.Why this is problematic
mob startalways resets the branch, regardless of local commits.Expected behavior
mob startshould detect local commits not on the remote and refuse to reset blindly.Example:
Alternatively, provide an option to rebase local commits instead of overwriting them.
Suggested improvements
1) Safety check before reset
If non-empty → abort
mob startwith clear instructions.2) Guidance after failed
mob nextWhen the push fails:
3) Optional rejoin-local mode
Automatically rebase local commits onto
origin/mob/maininstead of discarding them.Why this matters
Mob abstracts Git for collaboration. In this case, that abstraction hides a destructive Git operation, leading to silent data loss.
A simple safety check would prevent this from happening in real-world sessions.