Many of the use-cases for git reset/git checkout in this context are better served by the newer git restore command, which has much more intuitive flags like --source/--worktree/--staged.
I use the new commands, git switch in particular! One place where I still use git reset where I think I should use something else is git reset --hard. That is, I just want to wipe out all in-progress changes, and reset the state to HEAD.
I think this is not the intended use-case for git reset — I am not updating the branch, only the working copy and the index. It feels this use-case should be covered by git restore. But, if I am understanding it correctly, the equivalent restore command is
git restore -WS .
which feels conceptually complicated, as I need to pass three arguments to it.
Is there a convenient modern equivalent to git reset --hard which doesn’t misuse the reset?
I agree about git restore and would add that git switch replaces much of git checkout functionality. It’s ironic that I rarely use git checkout and git reset given that the posted article is basically how I learned about the git model.
You could just use jujutsu which doesn’t have a staging area and doesn’t distinguish commits from the working directory, therefore doesn’t need a complicated command to handle the state of all three things.
It’s also, therefore, presumably not capable of allowing people to work with the index as separate from the working copy if that’s what they want to do! It’s great that people are experimenting, and I think a crucial part of the success of jujutsu is that it’s essentially undetectable in its interoperability, but I don’t really believe it will be the right trade off for everybody, FWIW.
Something can be more uniform, simpler, while being equally or even more expressive – enabling more things than before. My experience with jj is that the tool (conveniently) supports a variety of workflows through its current capabilities, with an UI that keeps it convenient, while keeping a simplified mental model. jj commits/changes are used to represent the working copy (the tool mostly enforces this), but they can also be used like I would use git stash (for example to track several not-yet-committed experiments in parallel), and why not to have several levels of working copies, emulating a separate index / staging area. (Saying anything more specific would require details on specific workflows that rely on an index separate from the working copy.)
It is possible to treat the second to last commit in jujutsu as the functional equivalent of the staging area in git. Just split your working commit (selecting what to “stage”) and then squash the generated commit with its predecessor.
On a few occasions when scripting git I have got massive performance wins from using the staging area effectively, because it allows the script to wrangle tree objects without unpacking all the blobs to disk. It might be nice to be able to work with tree objects more directly, though it might be hard to get the same performance. In git you can mutate the staging area in place with a series of commands; if the staging area doesn’t exist then each command would have to create a new altered copy of the tree object. (The classic imperative vs purely functional performance problem.) I suppose it might be feasible to invert control, so instead of running a series of mutations, you provide a script that filters/mangles a representation of the tree — fixing the functional mutation problem by being more functional.
Did you read the text JordiGH linked to? We tried to address your concern there.
EDIT: Oh, you work for Oxide… Try talking to Steve Klabnik or Rain about Jujutsu. I don’t know how big Oxide is, so maybe you’re not even close to either of them.
I did, in fact! I’ve been following along inside the company (we do all talk a lot!) and with other discourse and writing online. My comment was mostly a response to what increasingly feels like (well intentioned!) propaganda that assumes everybody must be looking to change the software that they’re using, or that a different workflow can be objectively better for everyone.
To be clear, I am sure the software is capable of achieving the same things I’m achieving, albeit with a different mental model. It’s just not for me, at least not right now.
That makes sense. Sorry, I didn’t mean to add to the propaganda. I just wanted to address what I thought was a misunderstanding (it’s a very common misconception that the staging area is needed to achieve the kinds of workflows Git users use the staging area for).
Many of the use-cases for
git reset/git checkoutin this context are better served by the newergit restorecommand, which has much more intuitive flags like--source/--worktree/--staged.I use the new commands,
git switchin particular! One place where I still usegit resetwhere I think I should use something else isgit reset --hard. That is, I just want to wipe out all in-progress changes, and reset the state to HEAD.I think this is not the intended use-case for
git reset— I am not updating the branch, only the working copy and the index. It feels this use-case should be covered bygit restore. But, if I am understanding it correctly, the equivalent restore command iswhich feels conceptually complicated, as I need to pass three arguments to it.
Is there a convenient modern equivalent to
git reset --hardwhich doesn’t misuse the reset?That’s what I use; I’m not aware of a better way.
Looking through
git help restoreandgit help glossary, it seems likegit restore -WS :/may be the modern version ofgit reset --hard.I agree about git restore and would add that git switch replaces much of git checkout functionality. It’s ironic that I rarely use git checkout and git reset given that the posted article is basically how I learned about the git model.
… orrrrrrr!
You could just use jujutsu which doesn’t have a staging area and doesn’t distinguish commits from the working directory, therefore doesn’t need a complicated command to handle the state of all three things.
https://github.com/jj-vcs/jj/blob/main/docs/git-comparison.md#the-index
It’s also, therefore, presumably not capable of allowing people to work with the index as separate from the working copy if that’s what they want to do! It’s great that people are experimenting, and I think a crucial part of the success of jujutsu is that it’s essentially undetectable in its interoperability, but I don’t really believe it will be the right trade off for everybody, FWIW.
Something can be more uniform, simpler, while being equally or even more expressive – enabling more things than before. My experience with jj is that the tool (conveniently) supports a variety of workflows through its current capabilities, with an UI that keeps it convenient, while keeping a simplified mental model. jj commits/changes are used to represent the working copy (the tool mostly enforces this), but they can also be used like I would use
git stash(for example to track several not-yet-committed experiments in parallel), and why not to have several levels of working copies, emulating a separate index / staging area. (Saying anything more specific would require details on specific workflows that rely on an index separate from the working copy.)It is possible to treat the second to last commit in jujutsu as the functional equivalent of the staging area in git. Just split your working commit (selecting what to “stage”) and then squash the generated commit with its predecessor.
On a few occasions when scripting git I have got massive performance wins from using the staging area effectively, because it allows the script to wrangle tree objects without unpacking all the blobs to disk. It might be nice to be able to work with tree objects more directly, though it might be hard to get the same performance. In git you can mutate the staging area in place with a series of commands; if the staging area doesn’t exist then each command would have to create a new altered copy of the tree object. (The classic imperative vs purely functional performance problem.) I suppose it might be feasible to invert control, so instead of running a series of mutations, you provide a script that filters/mangles a representation of the tree — fixing the functional mutation problem by being more functional.
Did you read the text JordiGH linked to? We tried to address your concern there.
EDIT: Oh, you work for Oxide… Try talking to Steve Klabnik or Rain about Jujutsu. I don’t know how big Oxide is, so maybe you’re not even close to either of them.
I did, in fact! I’ve been following along inside the company (we do all talk a lot!) and with other discourse and writing online. My comment was mostly a response to what increasingly feels like (well intentioned!) propaganda that assumes everybody must be looking to change the software that they’re using, or that a different workflow can be objectively better for everyone.
To be clear, I am sure the software is capable of achieving the same things I’m achieving, albeit with a different mental model. It’s just not for me, at least not right now.
That makes sense. Sorry, I didn’t mean to add to the propaganda. I just wanted to address what I thought was a misunderstanding (it’s a very common misconception that the staging area is needed to achieve the kinds of workflows Git users use the staging area for).
This seems like the kind of obnoxiously fannish comment we Rustaceans get stereotyped as making about Rust.
And it worked for Rust, didn’t it? The RESF won.