[R0flcopt3r]

For you to enjoy using this tool you had to change the model your brain use, and you call that good UX? And using aliases means that your git is now different from you co-workers git. And when teaching the new guys you throw all these aliases at them that they have no idea what is or how work?

[ehnto]

Is it really so hard to imagine a tool that takes some thought to use?

I didn't know how to use a welder just by looking at it, but the UX is fine once you know the concepts behind welding.

I honestly can't see how git could be easier given the requirments of the tool. If you want to reduce its capabilities because it's too hard then go ahead, but please fork it or make something new instead of ruining a perfectly good developer tool.

I do find the division between git seems to be really concise. Either people don't get what the fuss is about or they think git is just the worst.

[martinvonz]

> I honestly can't see how git could be easier given the requirments of the tool.

If you're curious how it can be done (IMO), take a look at https://github.com/martinvonz/jj. It's its own VCS but also compatible with Git so individual developers on a team can migrate to it.

[pydry]

Knowledge of git has become a sort of status signifier. It "makes you a developer".

I think for this reason there's a lot less pushback on its bad UX than there would be for any other program. It would render knowledge of its arcane guts less...special. The juniors will be forced to deal.

It makes me wonder though, if needlessly arcane knowledge is and always was a part of other apprentice relationships.

[tehbeard]

How do you improve the ux though?

I see a lot of complaints about it, and agree that for all the porcelain, you do have to become familiar with the plumbing to solve issues.

But noones shown me a good alternate ux story, just different porcelain/fittings. I still have to reach under the sink because said new porcelain didn't stop/avoid a case sensitivity clash, or it barfed on a merge and left the repo still to merge.

[Espressosaurus]

Make it use Hg's CLI.

Mercurial and Git have, for most purposes, functionally identical capabilities. Atlassian at one point allowed you to checkout a project as either a git or a mercurial repo painlessly.

Mercurial's porcelain makes sense: the command is exactly what you think it is, usually without any funky modifying flags. If there are flags, they're often obvious, and if they're not, hg help <command> will clear that right up.

Contrast to git, which is a mishmash of commands and esoteric flags, and the help isn't even inlined.

The underlying concepts are easy enough, but how you access them requires memorization of arbitrary command sets that are inconsistent and overloaded.

Fix the porcelain and IMO you fix most of the problems with Git.

[xigoi]

Making the CLI self-consistent would be a big improvement.

[nextlevelwizard]

>"to use a tool the way it was intended you had to adjust to use the tool as it was intended to be used"

I sure wouldn't call that a _bad_ UX. As with any tool you have to adjust to the tool or make your own unless by some miracle someone shares your particular idiosyncrasies.

>"modifying tool makes it different from your co-workers tool"

Yes, but that is a big plus instead of a minus. If your co-workers asks how to do something you can just give them the content of the alias. I also alias `git` as `g` in my terminal. Is that going to cause problems for my co-workers? No.

Unless you are training a complete-fresh-out-of-school-junior the "new guy" should already know how git works and in either case that sounds like homework for them more than anything else.

[ewindal]

That’s a complete non sequitur. Everything we learn changes the way we view the world. You cannot make version control software without a data model that needs to be learned. Git’s model is very easy to visualize.

[sirmarksalot]

Depends what you mean by "change the model your brain [uses]". In terms of the fundamental model of how Git works, it perfectly describes what users actually want (get me the repo at revision X), but not what they expect (get me file A, revision 5, and file B, revision 7, and pray it builds).

In terms of the metaphors for the actual commands, I would agree. Reset and checkout basically make no sense for what they're actually used for. Switch makes things a bit better, but yeah, it would be nice if the entire Git CLI could be redesigned from scratch.

[bayindirh]

> For you to enjoy using this tool you had to change the model your brain use, and you call that good UX?

Every tool has its modus operandi, incl. but not limited to every programming language. Extending our understanding is hardly a bad thing.

Git proposes a model for handling stuff, and I prefer it very much.

And yes, the UX is fine.

[pdmccormick]

I've never understood the argument that you should not optimize your own working environment (IDE/editor customization, alternate keyboard layouts, shell aliases, custom hotkeys, scripts, etc.) because it could be unfamiliar to someone else. I've also heard it in the context of, you shouldn't stray too far from the defaults because if you sit down to use a colleagues' computer, you will be out of your element. Unless your job is to pair program full time, or perhaps you're creating educational screencasts, maybe? If you slowly build out your own personal setup over time, presumably you should still always be able to explain what it is that you're doing at each step.

[rsync]

Counterpoint: for me to enjoy using the bicycle tool I had to change models my brain used … and, yes, I think the bicycle has a good UX.