> I watched your demo video and I don't see any advantages over using named branches, and you describe no specific advantages in your README. It's hard to moti

> I watched your demo video and I don't see any advantages over using named branches, and you describe no specific advantages in your README. It's hard to motivate a workflow change, especially since this one adds no fundamentally new capabilities to Git. In the same way, the git-flow workflow offers no new capabilities, but some people still find it useful. As per the README, I find that it reduces the friction for dealing with these use-cases, compared to a branch-based workflow: * Switching between work tasks. * Separating minor cleanups/refactorings into their own commits, for ease of reviewability. * Extensively rewriting local history before submitting code for review. * Performing speculative work which may not be ultimately committed. * Working on top of work that you or a collaborator produced, which is not yet checked in. * Losing track of git stashes you made previously. Of course, you can do all this with branches too, and many people will prefer branches for these tasks. You have to be the kind of person who performs extensive "surgery" on your Git history. > but are names so bad that you're gonna adopt a non-standard git workflow? There's no interoperability problems between using this workflow and collaborating with others. In the worst case, you can always make a branch if you need to. > `git undo` is cool. There have been a number of fun variations on it over the years, and yours seems fine, but it's usually a leaky abstraction. I expect that yours is, too, but that's just because git itself is a leaky abstraction; it's just really hard to build a strong foundation on sand. The particular feature that this `git undo` provides that others don't is that it can undo bad rebases/amends/merges/etc. (without having to resort to the reflog). This seems to be an area that many beginner to intermediate Git users struggle with.