{"thread":{"id":"63731","subject":"Feature Request git snap, Lightweight Commit Workflow for Iterative Development","startedAt":"2025-07-02T18:30:51Z","lastAt":"2025-07-03T18:12:50Z","messageCount":5,"participants":["Suraj Bhadrike","Lucas Seiki Oshiro","brian m. carlson","Ben Knoble"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"521195","messageId":"CAPGv+4ZT774b-LGMFpyv3cJYUrpWPMpkCGn25AfwD7MHskbV=g@mail.gmail.com","threadId":"63731","inReplyTo":null,"subject":"Feature Request git snap, Lightweight Commit Workflow for Iterative Development","fromName":"Suraj Bhadrike","fromEmail":"surajbh2233@gmail.com","sentAt":"2025-07-02T18:30:17Z","receivedAt":"2025-07-02T18:30:51Z","isPatch":false,"sender":{"key":"surajbh2233@gmail.com","avatar":null},"body":"Hi Git contributors,\n\nThis proposal introduces a new command git snap  designed to support\nhighly iterative development workflows nowdays  influenced by AI\ncoding assistants.\n\nThe rise of AI assistants and agentic AI workflows has changed the\npace and nature of coding. A developer might cycle through dozens of\nvariations of a function or component in a short period while\ncollaborating with an AI.\n\nThis feature would provide a soft commit or snapshot capability,\nallowing developers to save their work state frequently and create a\nnew commit every time as a snapshot or checkpoint without a commit\nmessage and flag where We can provide an option for developers to\ninclude files at the start of snap Session.\n\nThe current Git workflow presents friction in this type of workflow.\n\nI've created a small Git repository with documents to help illustrate\nthe concept.\nPlease review it at your convenience :\nhttps://github.com/surajbh123/git-snap/tree/main\n\nYour feedback on this is highly valuable.\nThanks,\nSuraj Bhadrike\n"},{"id":"521199","messageId":"5662B201-C668-4D40-99BC-4C499813730A@gmail.com","threadId":"63731","inReplyTo":"CAPGv+4ZT774b-LGMFpyv3cJYUrpWPMpkCGn25AfwD7MHskbV=g@mail.gmail.com","subject":"Re: Feature Request git snap, Lightweight Commit Workflow for Iterative Development","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2025-07-02T19:38:44Z","receivedAt":"2025-07-02T19:39:00Z","isPatch":false,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"\n> Hi Git contributors,\n\nHi!\n\n> The rise of AI assistants and agentic AI workflows has changed the\n> pace and nature of coding. A developer might cycle through dozens of\n> variations of a function or component in a short period while\n> collaborating with an AI.\n\nThe use case for this features looks very clear to me!\n\n> The current Git workflow presents friction in this type of workflow.\n\nHowever, I still don't see that friction.\n\nEven though it's desirable to have a healthy commit history, when we\nare developing it's ok to create temporary and dirty commits and fixing\nthem later.\n\nLooking specifically to each of the problem in the \"problems\" section:\n\n1. Commit Overhead: I can't see what's the difference between the WIP\ncommits and the proposed snaps, which seems to be commits with empty\nmessages (that can be created with `git commit -m ''\n--allow-empty-message`);\n\n2. Indeed, that's not the purpose of stash;\n\n3. Manual rebasing: another option without rebasing + squashing is: \n\n```\ngit reset <last useful commit>\ngit add -A\ngit commit -m \"useful commit message\"\n```\n\nand thinking from the user perspective, currently we need to learn\n`git rebase -i`. Creating another command would make us learn the\nnew command and its use cases while we would still need to learn\n`rebase -i` for the other use cases.\n\nLooking to the features itself, the only one that looks new to me\nis the numbering from the oldest to the newest snap/commit. We can\nstill do that using HEAD~<n> but it counts from the newest commit\nto the oldest. We also can't (as far as I remember) list the commits\nusing the ~/^ syntax.\n"},{"id":"521214","messageId":"aGWq7vBSYuuKW69o@fruit.crustytoothpaste.net","threadId":"63731","inReplyTo":"CAPGv+4ZT774b-LGMFpyv3cJYUrpWPMpkCGn25AfwD7MHskbV=g@mail.gmail.com","subject":"Re: Feature Request git snap, Lightweight Commit Workflow for Iterative Development","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-07-02T21:55:58Z","receivedAt":"2025-07-02T21:56:00Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-07-02 at 18:30:17, Suraj Bhadrike wrote:\n> Hi Git contributors,\n> \n> This proposal introduces a new command git snap  designed to support\n> highly iterative development workflows nowdays  influenced by AI\n> coding assistants.\n> \n> The rise of AI assistants and agentic AI workflows has changed the\n> pace and nature of coding. A developer might cycle through dozens of\n> variations of a function or component in a short period while\n> collaborating with an AI.\n\nI mean, I do this too without an AI.  I frequently want to make changes\nuntil something works, and then snapshot it and modify it to polish it\nand make it more presentable.\n\n> This feature would provide a soft commit or snapshot capability,\n> allowing developers to save their work state frequently and create a\n> new commit every time as a snapshot or checkpoint without a commit\n> message and flag where We can provide an option for developers to\n> include files at the start of snap Session.\n\nI think a lot of this is achievable with current functionality, just in\na slightly different way.  At the beginning, you could save a set of\npathspecs in a file (equivalent to your `--include` and `--exclude`\noptions) and create a random ID (also in a file).  You then do `git add`\nwith your pathspecs and do a `git commit -m \"WIP: snap <random ID>\"`.\n\nFor subsequent commits, you can just do the same `git add` with the\npathspecs and then do a `git commit --squash HEAD` or `git commit\n--fixup HEAD`.  When you're done, you can use `git rebase --autofixup`\nto squash all the commits down into one.\n\nThese are things you can create with an alias pretty easily and I have\nsimilar functionality to make this easy.  Or you can create an external\n`git-snap` command that simply does this under the hood.  I don't think\nthis is functionality we need in core Git because we can already achieve\nmost of it pretty easily with a few shell aliases.\n\nIf you do create this as an external command, then please do not accept\nmultiple patterns in the `--include` and `--exclude` options; take\nmultiple options instead.  Git LFS did what you're proposing to do and\nit means that files or patterns with a comma in them can't be matched.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"521273","messageId":"88CDEF6D-A01C-46BB-A394-CE0E3C3F9B87@gmail.com","threadId":"63731","inReplyTo":"aGWq7vBSYuuKW69o@fruit.crustytoothpaste.net","subject":"Re: Feature Request git snap, Lightweight Commit Workflow for Iterative Development","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-07-03T13:13:47Z","receivedAt":"2025-07-03T13:13:59Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n> Le 2 juil. 2025 à 17:56, brian m. carlson <sandals@crustytoothpaste.net> a écrit :\n> \n> On 2025-07-02 at 18:30:17, Suraj Bhadrike wrote:\n>> Hi Git contributors,\n>> \n>> This proposal introduces a new command git snap  designed to support\n>> highly iterative development workflows nowdays  influenced by AI\n>> coding assistants.\n>> \n>> The rise of AI assistants and agentic AI workflows has changed the\n>> pace and nature of coding. A developer might cycle through dozens of\n>> variations of a function or component in a short period while\n>> collaborating with an AI.\n> \n> I mean, I do this too without an AI.  I frequently want to make changes\n> until something works, and then snapshot it and modify it to polish it\n> and make it more presentable.\n\nYep. I think of this as “locally I do whatever I want; polish before publish.”\n\n> \n>> This feature would provide a soft commit or snapshot capability,\n>> allowing developers to save their work state frequently and create a\n>> new commit every time as a snapshot or checkpoint without a commit\n>> message and flag where We can provide an option for developers to\n>> include files at the start of snap Session.\n> \n> I think a lot of this is achievable with current functionality, just in\n> a slightly different way.\n\nAgreed. My variant is something like\n\nRepeat: { hack && commit -m wip --amend }\n\nThe first commit omits the amend option, of course, and I can inspect previous snapshots with the reflog."},{"id":"521285","messageId":"CAPGv+4bPz4qbRowYtJo_BTmmkDaGQvDFCrjvAuBsso0rqOF3eQ@mail.gmail.com","threadId":"63731","inReplyTo":"88CDEF6D-A01C-46BB-A394-CE0E3C3F9B87@gmail.com","subject":"Re: Feature Request git snap, Lightweight Commit Workflow for Iterative Development","fromName":"Suraj Bhadrike","fromEmail":"surajbh2233@gmail.com","sentAt":"2025-07-03T18:12:41Z","receivedAt":"2025-07-03T18:12:50Z","isPatch":false,"sender":{"key":"surajbh2233@gmail.com","avatar":null},"body":"Hi Git contributors,\n\nThanks all for taking the time to review my proposal.You're all right,\nGit already has tools to get a similar result.\n\nExperienced Git users can set up shortcuts and alises and use tools\nlike fixup commits, rebase, and reflog,\nbut these can be hard to learn for beginners.A purpose to build snap\ncommands with simple syntax would make this workflow accessible to\nmore developers.\n\n> fixup /squash  commits\n> noisy logs branch fixup until final rebase.\n> git snap keeps temporary commits in its own log (git snap log), so git log stays clean throughout.\n\n>  commit --amend\n>  only “undo” in a straight line.\n> Reflog can recover old states, but isn't user-friendly or history maintained.\n> git snap checkout <id> gives direct access to any checkpoint easy exploration,\n\n>>> Workflow (Modified using your feedback)\n\n# Branch\ngit checkout -b feature/batch-processor\n\n# Begin snapshot session\n$ git snap start\n> Snapshot session started at 2025-dd-mm\n\n# these files will be tracked, and any further changes will be\nautomatically included in future snap commits. ( removed flag\napproach)\n$ git snap add batch_processor.py job_config.yml\n\n$ git snap commit\n> snap: 1 @ 2025-dd-mm hh-mm-ss (2 files)\n\n# Git snap will also track this\n$  git snap add batch_processor.py\n\n$ git snap commit -m \"Parallel processing implementation\"\n> snap: 2 @ 2025-dd-mm hh-mm-ss (3 files) - Parallel processing implementation\n\n$ git snap commit\n> snap: 3 @ 2025-dd-mm hh-mm-ss (1 files)\n\n$ git snap commit\n> snap: 4 @ 2025-dd-mm hh-mm-ss (1 files)\n\n\n$ git snap log\nID      Timestamp                   Files    Message(Optional)\n--      ---------                   -----    -------\n4       snap: 4 @ 18:25:18          1\n3       snap: 3 @ 18:10:35          2\n2       snap: 2 @ 17:45:22          3        Parallel processing implementation\n1       snap: 1 @ 17:35:15          2\n\n  $ git snap checkout 3\n> Working directory set to snap: 3\n\n$ git snap squash -m \"feat: Implement efficient batch processor with\nerror handling\"\n\n# Result: Clean history with one meaningful commit\n$ git log --oneline -n 1\n8d72e56 (HEAD -> feature/batch-processor) feat: Implement efficient\nbatch processor with error handling\n\nI appreciate the discussion and feedback.\n\nThanks,\nSuraj Bhadrike\n"}]}