GitTree Undo, Redo and recovery snapshots

• Read what the next Undo or Redo would do before you press it.
• Predict that undoing a commit keeps its changes staged, and that Redo can bring the commit back.
• Recognise why the app refuses an Undo or Redo: the branch moved, files changed, a remote was changed.
• Know what recovery snapshots are and how to delete old ones deliberately.

You are on private/undo-demo, a branch from lesson 18's result M with a clean work tree. You will create one small note, docs/signup-recovery.md, and commit it through GitTree, because GitTree's Undo works from the steps it records itself. A commit made in a terminal is a different thing and does not go into that record.

Everything is local and on the Free plan (GitTree asks you to sign in): no hosting account, no provider, no internet. Every identity is fictional (example.com). Never run this lesson in a real project.

Make the changes in GitTree or with the native Git commands, not both in the same copy. Reading the result is always safe. The menu labels, tooltips and notices come from GitTree 2.0's own strings and source. The native commands were run with Git 2.43 in disposable copies and show only the Git model, not the app's record. The GitTree steps were not run on macOS, Windows or Linux.

GitTree keeps a journal of the steps it performs. Undo reverses the newest step and Redo repeats the step undone last. The toolbar tooltip names the step, for example "Undo: commit …". Read it first: if it names something other than what you expect, stop.

Before a destructive step, GitTree saves a recovery snapshot under refs/ogt/trash/* and writes the journal entry. Undo restores from that record, and only while nothing has changed since: a branch is moved back only if it still points where the step left it, and files are restored only if nobody edited them after. Otherwise Undo is refused with a reason, and the snapshot is kept.

Undoing a commit moves the branch back and keeps the committed changes staged, so nothing is lost. Redo of that commit moves the branch forward again to the same commit. Not every step can be redone, and some cannot be undone: a force push changed a remote ("push again to change it back"); a deleted stash is kept as a snapshot but not undone yet; the very first commit has no earlier state. A step that stopped partway has no complete result to undo.

Snapshots are not deleted on a schedule. The command Delete Old Recovery Snapshots… lets you choose an age, shows exactly which snapshots are older, and deletes only those after you confirm. Deleting a snapshot removes the way back for that step.

Undo and Redo change only the local repository. Nothing is published.

Start from a separate ordinary copy of lesson 18's result M that you trust and leave your original untouched. Create the branch and make the note. DOC_LOST is the note's content.

Save only at the phase named below. These are full UTF-8/LF bodies with a final newline; never paste Markdown fences. Unchanged runnable files inherit the named input. Versions in separate variants must not overwrite the original.

docs/signup-recovery.md — DOC_LOST

# Recovered signup work

Keep a branch name before leaving useful experimental work.

Open the palette with Command+Shift+P (Ctrl+Shift+P on Ubuntu). Undo and Redo are in the toolbar and in the palette; the shortcuts are Command+Z for Undo and Command+Shift+Z or Command+Y for Redo (Ctrl on Windows and Linux).

1. In a separate copy, create the branch private/undo-demo and save DOC_LOST as docs/signup-recovery.md. Open the changes list: the file is new.
2. Stage only that file and commit it with the Summary docs: demonstrate a reversible local commit. Wait for the real result.
3. Hover Undo in the toolbar. The tooltip reads "Undo: commit …". If it names another step, stop: do not undo something you did not mean to.
4. Choose Undo once. The notice says "Undid: commit." The branch is back on M and the note is staged, not deleted.
5. Hover Redo. The tooltip reads "Redo: commit …". Choose Redo once. The notice says "Redid: commit." The commit is back and the work tree is clean.
6. Separate stale-state copy. In a second copy, repeat steps 1 to 4, then, outside GitTree, commit the staged note with git commit -m "docs: external move after app undo". Look at Redo: it is disabled, and its reason is "The branch moved since; undoing would overwrite that change." Do not force it.
7. Open the palette and run Delete Old Recovery Snapshots…. Leave Older than (days) at 30 and choose Find. Read what the list says: either "No snapshots are that old." or a list of the old ones. Close the dialog; do not delete anything to finish the lesson.

For every ordinary commit in the course: Summary is the stated subject, Description is empty and the options Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit and Allow Empty Commit stay off.

The terminal does not use the app's journal. This is the plain Git model of what the commit undo does, in a different clean copy of lesson 18's result:

git switch --create private/undo-demo
BEFORE_SHA="$(git rev-parse HEAD)"

Save DOC_LOST as docs/signup-recovery.md, then:

git add -- docs/signup-recovery.md
git commit --quiet -m "docs: demonstrate a reversible local commit"
AFTER_SHA="$(git rev-parse HEAD)"
git reset --soft "$BEFORE_SHA"
git status --short

A  docs/signup-recovery.md

The branch is back and the file is staged. Moving forward again:

git reset --soft "$AFTER_SHA"
git status --short

The status is empty. These commands do not call the app's Undo or Redo, record a GitTree journal entry or create a snapshot; git for-each-ref refs/ogt/trash prints nothing in this copy. In an app-made take it lists the real snapshot names, which you read without changing them.

The guard against a stale step is a compare-and-swap. Git has the same idea in update-ref, which moves a ref only if it still holds the value you expect. After an external commit:

git update-ref refs/heads/private/undo-demo "$AFTER_SHA" "$BEFORE_SHA"

Git refuses with "cannot lock ref … is at … but expected …". GitTree's own refusal is the one in the tooltip: "The branch moved since; undoing would overwrite that change."

Where you end: in the first copy the note was committed, undone (staged, branch on M) and redone (branch on the commit, tree clean). In the stale copy Redo was refused because the branch moved, and the external commit was left intact. You opened the snapshot dialog and closed it without deleting anything.

• Pressing Undo without reading the tooltip, and undoing a step you did not mean.
• Assuming every action can be undone or redone: a force push and a deleted stash are not, and most steps have no Redo.
• Expecting Undo to cover edits you made in an editor outside GitTree.
• Deleting old snapshots to tidy up, which removes the way back.

If Undo is disabled, read the reason in the tooltip: the branch moved, files were edited since, a remote was changed, or there is nothing to undo. If a step is refused, its recovery snapshot is kept under refs/ogt/trash/*; do not delete it while you are unsure. For commits made outside GitTree, use the reflog from lesson 29.

Answer each question, then read why. Questions marked “Required” count toward completing the lesson.

1. Question 1 of 6

   Question 1 of 6

   What should you do before pressing Undo?

   Choose one answer.

   Run a hard reset to be safe.

   Read the tooltip: it names the step Undo would reverse.

   Nothing: Undo always reverses your last click.

   Delete the old recovery snapshots first.

   Check answer
2. Question 2 of 6

   Question 2 of 6

   Which of these steps does GitTree refuse to undo, with a stated reason?

   Choose every answer that applies.

   A step after the branch moved on.

   A force push.

   The first commit of a repository.

   An ordinary commit made in GitTree on an unchanged branch.

   Check answer
3. Question 3 of 6

   Question 3 of 6Required

   You commit the note in GitTree and choose Undo once. What do you see?

   Choose one answer.

   The branch stays and the commit is marked as hidden.

   The branch is on M and the note file is deleted.

   Nothing changes, because the commit is shared.

   The branch is back on M and the note is staged, not deleted.

   Check answer
4. Question 4 of 6

   Question 4 of 6

   Change the input: after Undo, you commit the staged note outside GitTree, and then look at Redo. What do you see?

   Choose one answer.

   The journal is cleared.

   Redo is disabled: "The branch moved since; undoing would overwrite that change."

   Redo works and makes a second copy of the commit.

   Redo replaces your external commit.

   Check answer
5. Question 5 of 6

   Question 5 of 6Required

   Undo is greyed out and its tooltip says "Its recovery snapshot was deleted." What happened, and what do you do?

   Choose one answer.

   The snapshot for that step was removed, for example by Delete Old Recovery Snapshots…. That Undo is gone; for committed work, look in the reflog (lesson 29).

   The repository is corrupt.

   Undo is a paid feature.

   Press Undo harder, or restart the app.

   Check answer
6. Question 6 of 6

   Question 6 of 6Required

   In the plain-Git model copy, which readbacks show what a commit undo does?

   Choose every answer that applies.

   git for-each-ref refs/ogt/trash lists a GitTree snapshot of the reset.

   git for-each-ref refs/ogt/trash prints nothing in that copy.

   After git reset --soft "$AFTER_SHA", git status --short prints nothing.

   After git reset --soft "$BEFORE_SHA", git status --short prints A docs/signup-recovery.md.

   Check answer

Write down what the Undo tooltip said, what the branch and the staged list looked like after Undo, and what Redo did. In the stale copy, write the reason Redo gave. Then name one step the app cannot undo and say why.

• Read the tooltip before you press.
• Undoing a commit keeps its changes staged.
• A moved branch or edited files make Undo refuse; snapshots are kept.

• Reset: soft, mixed and hard (lesson 27)
• Find a lost commit with reflog (lesson 29)
• Download GitTree

Undo — تراجع; Redo — إعادة; journal — سجل العمليات; recovery snapshot — لقطة استعادة.