> 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.
