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

111–120 of 200 posts

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

#111

Post by Someone »

dotancohen wrote: post #51
amcoy37 wrote: post #29

Earlier quoted context omitted.

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.

I don’t see anybody here claiming that’s git’s fault.

But it is an argument supporting the claim being discussed: that the statement “It is very hard to permanently lose work” is not quite true.

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

#112

Post by mpawelski »

gorgoiler wrote: post #73

Thing I wish I’d learned sooner about git: it was designed to make patches a first class entity. Trees of objects are indeed the fundamentals, but it’s quite possible to detach a commit by formatting it into a patch (“git format-patch”) and sharing it outside of the context of a repo. No ssh required: email it, fax it, print it out and mail it — all the metadata is retained allowing the commit to be reconstituted as…

Yeah, it took me some time to get it that the concept of "patch" is actually quite fundamental in many git commands (rebase, cherry pick, merge (it's basically applying patches from common parent and other branch)). I wasn't used to those because as a developer who uses Windows, diff[0] and patch[1] were not popular there.

But I don't mind "Merge Request/Pul Request" that is basically everywhere now (github, gitlab, bitbucket, etc). It's clearly simpler for novice developer to get started with this workflow that with "patch workflow"

[0]https://en.wikipedia.org/wiki/Diff [1]https://en.wikipedia.org/wiki/Patch_(Unix)

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

#113

Post by TacticalCoder »

pdonis wrote: post #106
skrebbel wrote: post #7

Fwiw a branch isn't a named sequence of commits, it's just a label that points to a single commit. It's exactly the same as a tag except that git moves it when you make a new commit. Mercurial calls these bookmarks which IMO is a much better name because it works exactly like real bookmarks (in books, not browsers). A git branch feels a little bit like a branch of a tree because each commit points to their parent. Th…

> each commit points to their parent. Therefore, you don't need to track the entire sequence of commits in the branch but just the commit at the tip. This is not entirely true, because it is perfectly possible to create commit graphs in git in which there is not a single well-defined branch for some commits. So just knowing the branch labels at each tip is not sufficient to assign a single well-defined branch to ever…

Yeah I much preferred Mercurial from that standpoint. And branches there were correctly named branch. But you kinda, sorta, can get "what should have been called branches but don't exist in Git" by using named tags when you "start a branch" (a real branch I mean, not a Git "branch").

> Mercurial branches don't work like this: they are actually stored as part of each commit, so even with ambiguous commit graphs each commit still has a well-defined branch.

I wonder which operation would not be possible with Git had Git gone that way. And hence I wonder too what's that operation that Git can do and that Mercurial can't.

Honestly switching from Mercurial to Git this weird "branch that aren't branch at all" was the single most WTF feature of Git.

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

#114

Post by kjeetgill »

skrebbel wrote: post #7

Fwiw a branch isn't a named sequence of commits, it's just a label that points to a single commit. It's exactly the same as a tag except that git moves it when you make a new commit. Mercurial calls these bookmarks which IMO is a much better name because it works exactly like real bookmarks (in books, not browsers). A git branch feels a little bit like a branch of a tree because each commit points to their parent. Th…

I think bookmarks are a fine name but I don't really see quibble about branches, which I think are an even better name, but I know it's because I'm seeing it with my git goggles on.

Can you elaborate on what you think branches are a better reference to? What operations or concepts are better expressed in terms of them? I think I'm at the edge of an epiphany here ... but I'm not quite groking it yet.

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

#115

Post by nemetroid »

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…

> if you do 'git checkout [path]'

The entire point of that command is to discard local changes.

There is some risk of getting the different forms of checkout mixed up, though, so prefer using switch and restore instead. As far as I know, the only use case of checkout not covered by other commands is checking out a commit that doesn’t have a branch attached to it.

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

#116

Post by hsn915 »

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…

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

What about svn is intuitive? It was never intuitive to me. It always felt confusing.

Trying to deal with any system without having a mental model (even if high level) of what's going on will always cause problems. How do I know if `svn update` screws up my uncommitted changes? I never felt safe with svn because I had no idea what the commands could do to my files.

> My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface? This isn't so much me griping about git (although I am) but more a curious case for design theory. Would love to read serious analysis. 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.

This is actually pretty common. You just don't notice it when you are used to the interface.

The unix file system and command line tools come to mind.

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

#117

Post by nemetroid »

Someone wrote: post #111
dotancohen wrote: post #51

Earlier quoted context omitted.

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.

I don’t see anybody here claiming that’s git’s fault. But it is an argument supporting the claim being discussed: that the statement “It is very hard to permanently lose work” is not quite true.

Using the command specifically designed to permanently discard work seems ”very hard” to me.

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

#118

Post by kjeetgill »

masklinn wrote: post #53
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 structura…

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

Amen. We probably disagree on if we need less abstraction or better abstraction though.

For all the griping that git gets I really think it could be much worse. It's a somewhat inelegant shrink-wrap over its data structures but at least I can get at all the pieces I need.

I get that SQL works well for ad-hoc analysis and business cases, and a query planner is super useful there, but for service to service calls I'd love a language that let's me refer to the tables, the b-trees, row-ids, and lets me tell it what to do.

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

#119

Post by tmaly »

masklinn wrote: post #53
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 structura…

It seems then what is needed is a better way to onboard people to get them to that state of knowing.

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

#120

Post by kjeetgill »

mikewarot wrote: post #92

It was only recently that I learned GIT doesn't store deltas as it's core functionality, which is how I had presumed it works. It's just saving snapshots, and making up the deltas in retrospect, for purposes of merging, etc. In using it, you're always confronted with deltas, so it seemed that was how it worked. The command structure didn't correspond at all, and was thus very confusing. Git is really a contents addre…

> Git is really a contents addressable archive disguised as a version tracking system.

This is a great take. I think I got lucky that I went from "copying whole directories to save my work before a refractor" directly to git without leaning svn or anything else first.

Treating it as a snapshot management/copy-on-write content addressable storage + diffing utilities is a perfect way of thinking about it. I always wished LVM snapshots had git's CLI.

Post reply on HN