Feature Request git snap, Lightweight Commit Workflow for Iterative Development

Hi Git contributors,

This proposal introduces a new command git snap designed to support highly iterative development workflows nowdays influenced by AI coding assistants.

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.

This feature would provide a soft commit or snapshot capability, allowing developers to save their work state frequently and create a new commit every time as a snapshot or checkpoint without a commit message and flag where We can provide an option for developers to include files at the start of snap Session.

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

I've created a small Git repository with documents to help illustrate the concept. Please review it at your convenience : https://github.com/surajbh123/git-snap/tree/main

Your feedback on this is highly valuable. Thanks, Suraj Bhadrike

Hi!

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

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.

On 2025-07-02 at 18:30:17, Suraj Bhadrike wrote:

I mean, I do this too without an AI. I frequently want to make changes until something works, and then snapshot it and modify it to polish it and make it more presentable.

I think a lot of this is achievable with current functionality, just in a slightly different way. At the beginning, you could save a set of pathspecs in a file (equivalent to your `--include` and `--exclude` options) and create a random ID (also in a file). You then do `git add` with your pathspecs and do a `git commit -m "WIP: snap <random ID>"`.

For subsequent commits, you can just do the same `git add` with the pathspecs and then do a `git commit --squash HEAD` or `git commit --fixup HEAD`. When you're done, you can use `git rebase --autofixup` to squash all the commits down into one.

These are things you can create with an alias pretty easily and I have similar functionality to make this easy. Or you can create an external `git-snap` command that simply does this under the hood. I don't think this is functionality we need in core Git because we can already achieve most of it pretty easily with a few shell aliases.

If you do create this as an external command, then please do not accept multiple patterns in the `--include` and `--exclude` options; take multiple options instead. Git LFS did what you're proposing to do and it means that files or patterns with a comma in them can't be matched.

Yep. I think of this as “locally I do whatever I want; polish before publish.”

Agreed. My variant is something like

Repeat: { hack && commit -m wip --amend }

The first commit omits the amend option, of course, and I can inspect previous snapshots with the reflog.

Hi Git contributors,

Thanks all for taking the time to review my proposal.You're all right, Git already has tools to get a similar result.

Experienced Git users can set up shortcuts and alises and use tools like fixup commits, rebase, and reflog, but these can be hard to learn for beginners.A purpose to build snap commands with simple syntax would make this workflow accessible to more developers.

# Branch git checkout -b feature/batch-processor

# Begin snapshot session $ git snap start

# these files will be tracked, and any further changes will be automatically included in future snap commits. ( removed flag approach) $ git snap add batch_processor.py job_config.yml

$ git snap commit

# Git snap will also track this $ git snap add batch_processor.py

$ git snap commit -m "Parallel processing implementation"

$ git snap commit

$ git snap commit

$ git snap log ID Timestamp Files Message(Optional) -- --------- ----- ------- 4 snap: 4 @ 18:25:18 1 3 snap: 3 @ 18:10:35 2 2 snap: 2 @ 17:45:22 3 Parallel processing implementation 1 snap: 1 @ 17:35:15 2

  $ git snap checkout 3

$ git snap squash -m "feat: Implement efficient batch processor with error handling"

# Result: Clean history with one meaningful commit $ git log --oneline -n 1 8d72e56 (HEAD -> feature/batch-processor) feat: Implement efficient batch processor with error handling

I appreciate the discussion and feedback.

Thanks, Suraj Bhadrike