[dale_glass]

> I'm curious why corporate development teams always feel the need to spy on their users? Is it not sufficient to employ good engineering and design practices?

No, because users have different needs and thoughts from the developers. And because sometimes it's hard to get good feedback from people. Maybe everyone loves the concept of feature X, but then never uses it in practice for some reason. Or a given feature has a vocal fan base that won't actually translate to sales/real usage.

> Would Git have been significantly better if it had collected telemetry, or would the data not have just been a distraction?

I think yes, because git famously has a terrible UI, and any amount of telemetry would quickly tell you people fumble around a lot at first.

I imagine that in an alternate world, a git with telemetry would have come out with a less confusing UI 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.

[trinsic2]

I think the big problem with Telemetry is that it's too much of a black box. There is 0 transparency on how that data it really used and we have a long history of large corporates using this data to build prediction products that track people by finger printing behavior though these signals. There is too much at stake right now around this topic for people to trust any implementation.

[chrishill89]

Didn't Go propose opt-out telemetry but then the community said no?

Compilers and whatnot seem to suffer from the same problem that programs like git(1) does. Once you've put it out there in the world you have no idea if someone will still use some corner of it thirty years from now.

[throwaway27448]

> 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.

[dale_glass]

> 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.

[bfivyvysj]

> 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.

[dale_glass]

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.

[throwaway27448]

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!

[throwatdem12311]

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.

[chrishill89]

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]

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

[chrishill89]

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

[wongarsu]

A more intuitive git UI would reduce engagement. Do you really want to cut a 30 minute git session down to five minutes by introducing things like 'git restore' or 'git undo'? /s

[dijksterhuis]

> I think yes, because git famously has a terrible UI, and any amount of telemetry would quickly tell you people fumble around a lot at first.

1. git doesn’t have a UI, it’s a program run in a terminal environment. the terminal is the interface for the user.

2. git has a specific design that was intended to solve a specific problem in a specific way. mostly for linux kernel development. so, the UX might seem terrible to you — but remember that it wasn’t built for you, nor was it designed for people in their first ever coding boot camp. that was never git’s purpose.

3. the fact that every other tool was designed so poorly that everyone (eventually, mostly) jumped on git as a new standard is an expression of the importance of designing systems well.

[Centigonal]

"UI" is a category that contains GUI as well as other UIs like TUIs and CLIs. "UX" encompasses a lot of design work that can be distilled into the UI, or into app design, or into documentation, or somewhere else.

[dijksterhuis]

> “UX" encompasses a lot of design work that can be distilled into the UI

like how git needs you to “commit” changes as if you’re committing a change to a row in a database table? thats a design/experience issue to me, not an “it has commands” issue.

[ForHackernews]

UI means "user interface". For a CLI tool the UI is the commands and modifiers it offers on the terminal.

[dijksterhuis]

i lump those into user experience (UX) stuff as it’s more leaning towards “flow of user action” etc.

[ulbu]

ok, you do, doesn’t mean that the difference others make of it are necessarily wrong, as the tone of your first comment suggested.

[dijksterhuis]

i believe that those people are wrong :shrug:

doesn’t change the bigger, more important fact that the struggles people have with git stem from the system design. i.e. the thing that ultimately determines what commands people need to run in what order (see points 2 and 3).

[Rapzid]

Yeah, UI impacts UX.

Also git has a UI.

[incrudible]

Mercurial was better than Git on almost any metric, it eludes me why it lost out to Git, perhaps because it lacked the kernel hacker aura, but also because it did not have a popular repository website with cute mascot going for it. Either way, tech history is full of examples of better designs not winning minds, due to cost, market timing, etc. And now with LLMs being trained on whatever was popular three years ago, we may be stuck with it forever.

[gavinhoward]

Because Git was faster.

This mattered because speed is the killer feature [1], and speed is often seen by users as a proxy for reliability [2].

[1]: https://bdickason.com/posts/speed-is-the-killer-feature/

[2]: https://craigmod.com/essays/fast_software/

[JoshTriplett]

> Mercurial was better than Git on almost any metric, it eludes me why it lost out to Git

I used Mercurial, professionally, back when there were a half-dozen serious VCS contenders, to contribute to projects that used it. I disliked it and found it unintuitive. I liked Git much better. Tastes vary.

Git made me feel like I was in control. Mercurial didn't.

Mercurial's handling of branches was focused on "one branch, one working directory", and made it hard to manage many branches within one working directory.

Mercurial's handling of branches also made it really painful to just have an arbitrary number of local experimental branches that I didn't immediately want to merge upstream. "Welcome to Mercurial, how can I merge your heads right now, you wanted to do that right now, right?"

Git's model of "a branch is just a pointer to a commit, commits internally have no idea what branch they're on" felt intuitive and comfortable.