Hacker News Reader

Comment by popopopo | Hacker News Reader

wow.

> I'm incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits.

correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot.

I did and do this every time I have doubts. and with time you will understand how non-dangerous git commands are.

"dangerous" part comes from the user, not the software, and it is okay. when you accidentally kick a corner of a furniture, that does not make that furniture "dangerous".

View on HN

If this is the "correct" way to learn, the problems are not with the user.

A well designed ui should be learnable while being used - creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability.

> A well designed ui should be learnable while being used

Strongly disagree with that one. A UI that lets you work in the most efficient way (e.g. vi) can also be well designed, even if it's incredibly difficult to learn.

> creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability.

Again, strongly disagree. Git is a powertool. You don't let loose a powertool if you don't understand how it works. Creating a fresh learning repo is merely acknowledging that you don't know the tool well enough yet. There's nothing wrong with that.

There's a big difference between being noob-friendly and being user-friendly. Personally, I hate noob-friendly tools, because they tend to just get in the way.

> Strongly disagree with that one. A UI that lets you work in the most efficient way (e.g. vi) can also be well designed, even if it's incredibly difficult to learn.

See, I don't think you do disagree. I said a UI should be learnable while being used - vi is. I said nothing about it that learning needing to happen quickly.

I use vim every day; it's not my primary editor, but I'm incredibly comfortable with it, which I wasn't for years after I started using it. But during those years of learning, I never got stuck with an unusable dev environment, I never lost data, I never had to Google how to proceed in order to get my work done. If I ran into a problem, I had the option of opening an alternative editor and continuing with my nice non-corrupted dev env, or I could choose to spend some time figuring out the vim way (and learn something).

vi/vim have no foot guns.

Perhaps this comparison is slightly unfair to git - vi is much simpler insofar as a modal interface is a simpler concept to grok than directed acyclic graphs. So they're not directly comparable, since vi's main barrier to learning is memorising commands and git's is conceptual. However - as has been mentioned elsehwere - hg makes a fine candidate in that regard.

> If this is the "correct" way to learn, the problems are not with the user.

OP's advice was essentially to first learn how to use a tool in a sandbox before screwing up mission-critical services. I really don't understand why you perceived the need to learn how to use a tool in a sandbox as problem that lies somewhere else other than the clueless newbie who's taking his first steps.

Letting toddlers learn how to ride a bike by installing training wheels doesn't mean that bicycles are flawed or poorly designed.

a still, while people cry about UI (which is irrelevant part), other people just take time and learn git. by whatever measures.

PS. throwing out things you test on. isn't that how every programming tutorial works? write code NOT in your main repository, test things out, throw it away (or keep it, whatever)?

> UI (which is irrelevant part)

UI usability is irrelevant... ?!??

> isn't that how every programming tutorial works

Firstly, learning programming and learning to use a tool that is a component of your workflow are two independent things. The latter should generally (ideally) have a much lower (aiming towards zero) learning curve. Yes, this is possible, with good UI design.

Secondly, even programming language designers strive towards lowering this learning curve. There is, imo, a necessary complexity, or "table stakes" for any reasonably useful language, but its still very evident to any language designer that this is a trade-off. Usability is desirable.

For a tool as popular and essential as Git, usability should be a much more central goal than it seems to have been in the past.

Is writing programs and building them a part of your workflow? Do you even spend time on setting up your build? On acquiring an actual understanding of how it works?

Other tools are no different. If it's an important tool, it pays to actually study it. Do not expect tools to do what you mean before you know well what you mean.

I think you're misinterpreting my post. I completely agree, you're absolutely right, but there's a huge different between what you're saying and what the gp was: that usability should not be a consideration for these tools.

I do understand, in quite a bit of depth (which I'm sure is still far from complete), how Git works. I still prefer to use Mercurial because it doesn't require me to be continuously aware of the dangers of those internals on a day-to-day basis - it doesn't supply me with a loaded foot gun. Sadly, I use Git every day, and rarely Mercurial, because that's what the masses have chosen and I've found using in-between compat tools not to be worth the extra hassle for me.

OK, I can agree: git is not as safe, mistake-proof, or consistent as it could be.

What I like about git is that it gives a simple algebra of patches (diffs), and allows almost any sensible operation over them.

It would be great to build a different CLI on top of the same data structures (and maybe the same plumbing) that would expose a more consistent and usable interface, while allowing for [most of] the same capabilities, and preserving interoperability. I suppose git-hg tries to achieve something similar, too.

For me, much of the pain of git CLI was alleviated first by a set of aliases, and then by using magit from within emacs.

With a programming language, if you open a new file A in the same repo and try out some stuff, and it doesn't turn out well, you can just delete the file and be reasonably sure that it doesn't fuck up files B, C and D in the same directory.

No but if occasionally the furniture kicks you, then it could be improved on, pointing out flaws in the best of the best is very worthwhile, it's in that pain space that the biggest usability gains are to be had.

> when you accidentally kick a corner of a furniture, that does not make that furniture "dangerous".

When the piece of furniture has a serrated corner that cuts deep into your toe, you'll probably reevaluate the appropriateness of your metaphor.

oh, so if you are careless, that's furniture's fault. okay. your comment is not the best counter to my point either.

PS: i have a lot of furniture with rought edges. I've learned my lesson, and furniture is not a problem anymore.

> correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot.

What if your repo with full history is about 30gb?

Why are you learning how to use hit by testing commands on a 30gb repo?

Reply on news.ycombinator.com