Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I wish everyone knew about Git (Part I)

blog.plover.com

Post reply on HN
Print view View original

51–60 of 200 posts

Re: Things I wish everyone knew about Git (Part I)

#51

Post by dotancohen »

amcoy37 wrote: post #29
atq2119 wrote: post #24

Earlier quoted context omitted.

> Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree. Not by default it won't. It can do that, if you explicitly run it with the options to checkout a specific path. But why would you do that if it's not what you want?

Accidentally running a git command in the wrong folder is pretty easy to do at the command line. I was, at one point, in the habbit of running "git checkout ." after writing some experimental code. Several times a day, or however often. So of course, I once accidentally ran that command in the wrong repo and obliterated some pending changes that hadn't been commited.

How is that git's fault?

I used to `vim test.c` then `rm Alt-.` very very often. Until one day sure enough I'm in the wrong directory, and I actually saw `Alt-.` complete the filename of an important file, but the brain veto latency is slower than the muscle memory twitch and my pinky continued on over to the Enter key.

I blame only Dotan and changed my work habits. Bash had nothing to do with the incident.

Re: Things I wish everyone knew about Git (Part I)

#52

Post by radarsat1 »

intrepidhero wrote: post #12

> But if you try to understand the commands without the model, you will suffer, because the commands do not make sense. I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? This seems like a similar situati…

> Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc?

I've used svn and git extensively, but after getting very used to git, i tried working on a project that used mercurial and walked away completely confused by how it works. With "branches" being completely different beasts that i couldn't understand and unsure when it was appropriate to use bookmarks instead. It completely baffles me that people find it better than git's super straightforward dag-of-snapshots model and I reject the idea that it is simpler or more intuitive.

Re: Things I wish everyone knew about Git (Part I)

#53

Post by masklinn »

intrepidhero wrote: post #12

> But if you try to understand the commands without the model, you will suffer, because the commands do not make sense. I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? This seems like a similar situati…

> My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation.

Dozens have, but by the time their replacement porcelain gets anywhere near useful they’ve attained a grasp of the plumbing more than good enough they don’t need it anymore.

> My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface?

Mastery of structural elegance doesn’t mean you have also mastered interface and experience. In fact it’s often not the case.

> I can't offhand think of another piece of software where "the model is elegant but the interface is confusing" is such a common critique.

Every database. The relational model is a beautiful thing, sql is a horrendous shit-show.

Re: Things I wish everyone knew about Git (Part I)

#54

Post by dotancohen »

throw7 wrote: post #20

Isn't "naming things" one of those "hard things" to do well in computer science? It seemed to me, linus and the initial git architects just kind of slapped names on operations as features grew organically over top of the model. To early adopters, all of it made sense. Yeah, someone new looking in from the top down will be bewildered.

Git reused much of the terminology of other VCS systems, even though the architecture was completely different.

So usage-wise git was familiar to someone familiar with e.g. SVN right from the beginning.

Re: Things I wish everyone knew about Git (Part I)

#55

Post by hinkley »

Anunayj wrote: post #31
tomjakubowski wrote: post #10

Earlier quoted context omitted.

just to spell it out fully for dear reader: that's how merge commits work.

and Just for fun, sometimes it can be as big as 66, meet Cthulhu merge [1] 1. https://lkml.org/lkml/2014/1/21/361

Linus doesn't appear to be particularly enthusiastic about this strategy.

Humans really do handle treating changes as a sequence. I wonder if this was really necessary or could have been serialized.

Re: Things I wish everyone knew about Git (Part I)

#56

Post by auraham »

atq2119 wrote: post #24
lisper wrote: post #11

> But if I were going to tell everyone just one more thing, it would be: > It is very hard to permanently lose work. Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree [UPDATE: if you do 'git checkout [path]', but that is not an uncommon thing to do.] It is true that it is very hard to lose work that you have committed. But even this is not…

> Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree. Not by default it won't. It can do that, if you explicitly run it with the options to checkout a specific path. But why would you do that if it's not what you want?

IIRC mercurial creates backup (.bak) files when restoring a file. As a result, you can keep changes in .bak files even after (accidentally) doing a `git checkout -- file` in mercurial. Git does not have that feature.

Re: Things I wish everyone knew about Git (Part I)

#57

Post by evanrelf »

chx wrote: post #30

> When I first used Git it drove me almost to tears of rage and frustration. But I did get it under control. I don't love Git, but I use it every day, by choice, and I use it effectively. Yes. For me the rescue was Charles Duan's git tutorial: Understanding Git conceptually. https://www.sbf5.com/~cduan/technical/git/ > you can only really use Git if you understand how Git works. Merely memorizing which commands you s…

That `git cd` command is a great idea! Thanks for sharing.

Re: Things I wish everyone knew about Git (Part I)

#59

Post by masklinn »

throw7 wrote: post #20

Isn't "naming things" one of those "hard things" to do well in computer science? It seemed to me, linus and the initial git architects just kind of slapped names on operations as features grew organically over top of the model. To early adopters, all of it made sense. Yeah, someone new looking in from the top down will be bewildered.

The worst part is that many of the names were inherited from earlier tools, but usually mangled, or repurposed because the old version was “not needed” (revert) because they’d merged multiple high-level features in the same command out of low-level commonalities (checkout and add being poster children for this)

Re: Things I wish everyone knew about Git (Part I)

#60

Post by masklinn »

dotancohen wrote: post #54
throw7 wrote: post #20

Isn't "naming things" one of those "hard things" to do well in computer science? It seemed to me, linus and the initial git architects just kind of slapped names on operations as features grew organically over top of the model. To early adopters, all of it made sense. Yeah, someone new looking in from the top down will be bewildered.

Git reused much of the terminology of other VCS systems, even though the architecture was completely different. So usage-wise git was familiar to someone familiar with e.g. SVN right from the beginning.

Except that’s not true because a lot of the commands git reused do something rather to completely different from their role in svn.
Post reply on HN