Re: changes for adding new features --snapshot,

From: Chris Torek <chris.torek@gmail.com>
Date: Dec 19, 2025, 11:05 UTC
Message-ID: <CAPx1Gvfuacq0rt-6LymiEUUdeKsE0+s8x2x66_zD=zatWui0RQ@mail.gmail.com>
In-Reply-To: <03034879-2d8e-4ab1-96ff-ff125e7d059e@gmail.com>

On Fri, Dec 19, 2025 at 2:41 AM Phillip Wood <phillip.wood123@gmail.com> wrote:

Show 5 quoted lines

> It would be helpful if there was a commit message explaining what this
> new feature is and why it is needed. There are some comments in the code
> explaining what it does but not why it is useful. Given that a commit is
> a snapshot of the working copy I'm not sure why you'd want to save an
> additional copy.

To be a bit more precise, a commit is just a little bit more than a snapshot of all staged files: it consists of a *tree object*, which is this snapshot, plus a *commit object*, which contains metadata to explain who made the commit, when, and why, and what commit(s) come immediately before the new commit.

The sample code itself makes copies of some (but not all) staged files, rather than a complete snapshot of all staged files. Abdullah is probably under the impression that Git saves only *changed* files, and that the staging area therefore contains only these changed files, but that's not the case: every snapshot contains *every* file.

This takes no extra disk space because of Git's clever method of storing snapshots. The code in the diff does not make use of this clever method; instead, it makes clumsy actual copies, which generally do take up extra disk space. That's presumably why there's a `--name-only` diff here:

>> git diff --name-only --cached | xargs -I{} cp --parents {} \"%s\"

To make a Git-style snapshot containing all files but using no extra space, we could more simply run `git commit-tree`, which produces the tree hash ID; we'd then save that somewhere that Git can find it so that Git won't garbage collect the tree later. The obvious place to save it is in a tag-like reference (perhaps an actual tag, perhaps some new `refs/snaps/` space or similar). But it's probably superior simply to create an actual commit, without putting it on any branch, in the same way that `git stash` makes commits but puts them on no branch.

In any case, you (Phillip) are right that this doesn't explain the use case for these extra "snapshot" commits or trees. I rather suspect that the intended use is better-served simply by making a branch (as often seems to me to be the cases for which people use `git stash`...).

Chris