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)

▲

throwaway27448 2 hours ago | parent [-]

At the hidden cost of educating millions of users how git actually operates once they can't restore a file

▲

chrishill89 2 hours ago | parent [-]

Neither of these two commands are any more really-operates than the other.

▲

throwaway27448 2 hours ago | parent [-]

How do you figure? Are you discarding the semantics of how people invoke git? If so why advocate for "restore" to begin with?

	▲	chrishill89 29 minutes ago \| parent [-]
		I don’t know what the semantics of invoking Git means? These two commands operate on the same level of abstraction. And they should be equally powerful, which means that whichever you choose to learn will be able to serve all of your restore-content needs. That's what I mean. Of course there is always the pedagogic cost of having two similar commands.