3 ms·
There is a design for undoing changes to the staging area: https://github.com/arxanas/git-branchless/issues/10 https://github.com/arxanas/git-branchless/issues/
by arxanas 5y ago
There is a design for undoing changes to the staging area: https://github.com/arxanas/git-branchless/issues/10 https://github.com/arxanas/git-branchless/issues/10
The similar project [Jujube](https://github.com/martinvonz/jj https://github.com/martinvonz/jj) has experimented with backing up even unstaged changes after every command, and apparently it works well for them, so we could do the same in the above design.
Undoing even untracked changes might be a bit much.
- lisper 5y agoYeah, this barely scratches the surface though. Take branching, which is something you're supposed to be doing all the time. So abstractly, I want to be able to get a list of my current branches, create a new branch, check out an existing branch, delete an existing branch, and maybe rename a branch. I would expect the commands for these operations to be something like: git branch list git branch create [name] git branch delete [name] git branch rename [old-name] [new-name] We can argue over whether checking out a branch should be "git branch checkout [name]" or just "git checkout [name]", but in either case, if I have unsaved changes in my working directory, I would expect to at least get a warning about this before that work got clobbered. None of these things are actually the case. Git checkout will clobber unsaved changes in my working directory. "Git branch list" is just "git branch". "git branch create" is "git branch [name]". So creating a branch is the SAME COMMAND as the one you use to produce a list of current branches, just with an argument. Madness. And this is the rule, not the exception. Minor variations on a theme can result in radically different commands with various mysterious arguments. There is no rhyme or reason or regularity. The only way to know is to look it up.
- akersten 5y ago> Git branch list" is just "git branch". "git branch create" is "git branch [name]". So creating a branch is the SAME COMMAND as the one you use to produce a list of current branches, just with an argument. Madness. And this is the rule, not the exception. As a counter-opinion, I actually like it this way. Especially since it's the rule and not the exception. When one makes the small effort to learn the commands, the payoff in saved keystrokes from avoiding typing the redundant pieces is great. As a painfully simplified justification: Directory listing is "ls" and removing a directory is "rmdir" - I much prefer that to typing a hypothetical "directory list" and "directory delete", even if the later fits some nice consistent shape. It's one of the reasons I hate powershell/windows-style CLI and its 60-character long arguments for every function.
- lisper 5y agoThere's nothing wrong with having a UI for power users in addition to a more intuitive one. But having a power-user UI as the only option (or even as the default) is not so good.
- seoaeu 5y agoIn particularly well designed UIs, the interface for power users and the intuitive one are one and the same!
- munificent 5y ago> "git branch create" is "git branch [name]". I've been using Git professionally for of a decade and you just taught me something new. I always use `git checkout -b [name]` (which is a completely bananas UX, but it's the one I know).
- seoaeu 5y agoThe two commands aren't actually equivalent, because of course they're not. Usually when you create a new branch you'd like to switch to it, but git branch [name] actually doesn't do that, so you have to execute a second command after.
- atoav 5y agoCheckout should be load or open.