Comment by throwaway27448
8 hours ago
> because git famously has a terrible UI
Thankfully, github has zero control over git. If they did have control they would have sank the whole operation on year one
> because somebody would have looked at the stats and for instance have added "git restore" right from the very start, because "git checkout -- foo.txt" is an absolutely unintuitive command.
How is git restore any better? Restoring what from when? At least git checkout is clear in what it does.
> How is git restore any better? Restoring what from when? At least git checkout is clear in what it does.
And this is exactly where disconnects happen, and where you need telemetry or something like it to tell you how your users actually use the system, rather than imagining how they should.
A technical user deep into the guts of Git thinks "you need to check out again this specific file".
A novice thinks "I want to restore this file to the state it had before I touched it".
Now we can argue about whether "restore" is the ideal word here, but all the same, end users tend to think it terms of "I want to undo what I did", and not in terms of git internals.
So a hypothetical git with telemetry would probably show people repeatedly trying "git restore", "git undo", "git revert", etc, trying to find an undo command.
> A technical user deep into the guts of Git thinks "you need to check out again this specific file".
This is a fundamental misunderstanding of both the user base who are by design all technical, and the use case that this tool serves: deeply technical and specific actions to a codebase.
Git is not just software. It is also a vernacular about how to reason about code change. You can't just make arbitrary commands do magic stuff by default and then expect that vernacular to be as strong as it is today.
Those "ergonomics" you're asking for already existed in other tools like CVS and subversion, they are specifically why those tools sucked and why git was created.
Nonsense. The "git restore" command is now an official part of git, and nothing is being lost because it's technically a git-checkout underneath. It's just a thin UI on top for convenience, nothing is being sacrificed. The old commands still work just like before.
CVS and Subversion have nothing to do with this, they were extremely different to Git in the way they worked and lost for many reasons that have nothing to do with having command names understandable to normal people.
I don't think this is worth the effort. A user either tries to understand the data structures underlying the tool or they don't. We don't market cars to babies, right? We don't pretend the car floats around—it's inherently based on engines and wheels, and the user must understand this to operate it safely. Similarly, git is inherently based around objects and graphs, and its operations should reflect this. "Restore" has simply no meaning in this world. Restore what to when in a world where time doesn't exist?
Surely, telemetry should help educate the tool maker to reveal the underlying model rather than coercing the model to reflect a bastardized worldview (as restore seems to).
Trying to wedge git into workflows that don't operate around git seems like a fool's errand. Either we must build tools around the workflow, or we must build the workflow around the tool.
This is part of why I find jujustsu so unintuitive: there is no clear model it's built around, only some sense of how to work with files I apparently lack. But perhaps it is the perfect tool for some workflow I have not yet grasped!
It’s total waste of time because both are going to be maintained in perpetuity. Increasing the maintenance burden and attack surface of git.
“a novice thinks”
Just learn your damn tools and stop whining.
The git-restore(1) implementation looks like about 35 lines of code. Then add a little more complexity for some apparent common functions that needed to be factored out.
For a dedicated "restore" it's worth it to me... (who will not maintain it)
5 replies →