Re: Feature Request git snap, Lightweight Commit Workflow for Iterative Development

From: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
Date: Jul 2, 2025, 19:38 UTC
Message-ID: <5662B201-C668-4D40-99BC-4C499813730A@gmail.com>
In-Reply-To: <CAPGv+4ZT774b-LGMFpyv3cJYUrpWPMpkCGn25AfwD7MHskbV=g@mail.gmail.com>

> Hi Git contributors,

Hi!

> The rise of AI assistants and agentic AI workflows has changed the
> pace and nature of coding. A developer might cycle through dozens of
> variations of a function or component in a short period while
> collaborating with an AI.

The use case for this features looks very clear to me!

> The current Git workflow presents friction in this type of workflow.

However, I still don't see that friction.

Even though it's desirable to have a healthy commit history, when we are developing it's ok to create temporary and dirty commits and fixing them later.

Looking specifically to each of the problem in the "problems" section:

1. Commit Overhead: I can't see what's the difference between the WIP
commits and the proposed snaps, which seems to be commits with empty
messages (that can be created with `git commit -m ''
--allow-empty-message`);

2. Indeed, that's not the purpose of stash;

3. Manual rebasing: another option without rebasing + squashing is:

``` git reset <last useful commit> git add -A git commit -m "useful commit message" ```

and thinking from the user perspective, currently we need to learn `git rebase -i`. Creating another command would make us learn the new command and its use cases while we would still need to learn `rebase -i` for the other use cases.

Looking to the features itself, the only one that looks new to me is the numbering from the oldest to the newest snap/commit. We can still do that using HEAD~<n> but it counts from the newest commit to the oldest. We also can't (as far as I remember) list the commits using the ~/^ syntax.