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

Picturing Git: Conceptions and Misconceptions

biteinteractive.com

Post reply on HN
Print view View original

11–20 of 105 posts

Re: Picturing Git: Conceptions and Misconceptions

#11

Post by Quenty »

wokwokwok wrote: post #4

hm. vexing. I feel like this is mostly accurate, to my knowledge, but reading this: > I do not claim that this way of looking at Git represents absolute “facts” in any hard and fast or literal sense. But I contend that if you conceive of Git in the way that I’m going to suggest, if you substitute these conceptions of Git for any misconceptions you might have now, you’ll be a much happier and more fluid Git user. …vex…

This article presents an accurate picture of how things work at a high conceptual level. It glosses over certain details, because git is very complex. For example, git has, if I recall correctly, 4 staging areas, of which represent different sources when it comes to a merge conflict. However, this detail can mostly be ignored because it’s not relevant to the high level conceptual ideas this article is trying to present.

I would argue most things in technology are complex, and mental models are intentional ways to take something complex and turn it into something more simple. This article does not create meaningless metaphors.

Re: Picturing Git: Conceptions and Misconceptions

#12

Post by megous »

bironran wrote: post #9

Ugh. So many concepts. So many things to remember. Why? Git is simple. SIMPLE. But only, IMO, if you go bottom-up and not top-down. There are only 6 critical concepts in Git and each is simple enough to be described in a single sentence. 1. Commits are immutable blobs that have one or more parents. Graphs, not trees. Anyone who uses trees for git commits misses the whole point and makes their (and their collaborators…

Reminds me of:

    Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

    -Linus Torvalds
Anyway, it's not for everyone to get to understand git this way, I guess. Some people will just react "just tell me how to do X in git!"

Re: Picturing Git: Conceptions and Misconceptions

#13

Post by kubanczyk »

bironran wrote: post #9

Ugh. So many concepts. So many things to remember. Why? Git is simple. SIMPLE. But only, IMO, if you go bottom-up and not top-down. There are only 6 critical concepts in Git and each is simple enough to be described in a single sentence. 1. Commits are immutable blobs that have one or more parents. Graphs, not trees. Anyone who uses trees for git commits misses the whole point and makes their (and their collaborators…

2. Tags are named, mutable pointers to commits.

3. Branches are named, mutable pointers to commits, that you can "ride". While you "ride" a branch it keeps moving to always point to your latest commit.

4. HEAD is an implicit branch that you "ride" at all times.

Re: Picturing Git: Conceptions and Misconceptions

#14

Post by bironran »

megous wrote: post #12
bironran wrote: post #9

Ugh. So many concepts. So many things to remember. Why? Git is simple. SIMPLE. But only, IMO, if you go bottom-up and not top-down. There are only 6 critical concepts in Git and each is simple enough to be described in a single sentence. 1. Commits are immutable blobs that have one or more parents. Graphs, not trees. Anyone who uses trees for git commits misses the whole point and makes their (and their collaborators…

Reminds me of: Bad programmers worry about the code. Good programmers worry about data structures and their relationships. -Linus Torvalds Anyway, it's not for everyone to get to understand git this way, I guess. Some people will just react "just tell me how to do X in git!"

Like a lot of things Linus, it's very pretentious and aloof but right at the core of it. Code matters a lot and bad code can tank performance, stop evolution and introduce security issues. But with Git, this is a mostly truthful statement.

Re: Picturing Git: Conceptions and Misconceptions

#15

Post by 8372049 »

jimbob45 wrote: post #5
darekkay wrote: post #3

That's the blog post I always wanted to write. So many people spend little to no time to actually learn Git, because "it's just a tool to help you doing your "real" work" (=coding) . Or because "Git is too difficult/confusing/broken". Or because "I don't need anything except commit/push/pull". I find those arguments somewhat true, but I still feel that people are missing out when they don't learn a tool they use dail…

It is just a tool to help you do your real work and famously gets in the way. You use SVN and it covers 99% of use cases much more simply than Git manages.

When you write things like that, you come across as trolling. Their point wasn't git vs. another tool, their point was the importance of knowing intricate details about your tools in certain circumstances.

If SVN is wonderful for you: Great! But that's not really relevant to the issue of using git effectively.

Re: Picturing Git: Conceptions and Misconceptions

#16

Post by globular-toast »

bironran wrote: post #9

Ugh. So many concepts. So many things to remember. Why? Git is simple. SIMPLE. But only, IMO, if you go bottom-up and not top-down. There are only 6 critical concepts in Git and each is simple enough to be described in a single sentence. 1. Commits are immutable blobs that have one or more parents. Graphs, not trees. Anyone who uses trees for git commits misses the whole point and makes their (and their collaborators…

This is the way I understand git. For me it's dead simple. I've tried to teach others over the years. Not a single person has got it so far.

Re: Picturing Git: Conceptions and Misconceptions

#17

Post by bironran »

kubanczyk wrote: post #13
bironran wrote: post #9

Ugh. So many concepts. So many things to remember. Why? Git is simple. SIMPLE. But only, IMO, if you go bottom-up and not top-down. There are only 6 critical concepts in Git and each is simple enough to be described in a single sentence. 1. Commits are immutable blobs that have one or more parents. Graphs, not trees. Anyone who uses trees for git commits misses the whole point and makes their (and their collaborators…

2. Tags are named, mutable pointers to commits. 3. Branches are named, mutable pointers to commits, that you can "ride". While you "ride" a branch it keeps moving to always point to your latest commit. 4. HEAD is an implicit branch that you "ride" at all times.

afaik, the commit a tag points to is immutable unless you delete and recreate (and then nothing is immutable really).

re "ride" - that's exactly what I'm trying to avoid. It's an additional concept that isn't needed to understand Git. You need to understand the model. The "ride" is an emergent property of the model and commands that you eventually understand, but not a core part.

Re: Picturing Git: Conceptions and Misconceptions

#18

Post by sagonar »

jimbob45 wrote: post #5
darekkay wrote: post #3

That's the blog post I always wanted to write. So many people spend little to no time to actually learn Git, because "it's just a tool to help you doing your "real" work" (=coding) . Or because "Git is too difficult/confusing/broken". Or because "I don't need anything except commit/push/pull". I find those arguments somewhat true, but I still feel that people are missing out when they don't learn a tool they use dail…

It is just a tool to help you do your real work and famously gets in the way. You use SVN and it covers 99% of use cases much more simply than Git manages.

If svn covers 99% of your use cases, then you need more experience with distributed version control systems.

Able to commit locally, examine changes work with them and then push is a something you might not need or require if you think about version system like SVN.

But if you have learned Git or Mercurial or some other distributed system you would never go back to svn.

Re: Picturing Git: Conceptions and Misconceptions

#19

Post by lvass »

bironran wrote: post #17
kubanczyk wrote: post #13

Earlier quoted context omitted.

2. Tags are named, mutable pointers to commits. 3. Branches are named, mutable pointers to commits, that you can "ride". While you "ride" a branch it keeps moving to always point to your latest commit. 4. HEAD is an implicit branch that you "ride" at all times.

afaik, the commit a tag points to is immutable unless you delete and recreate (and then nothing is immutable really). re "ride" - that's exactly what I'm trying to avoid. It's an additional concept that isn't needed to understand Git. You need to understand the model. The "ride" is an emergent property of the model and commands that you eventually understand, but not a core part.

See git tag -f.

Sometimes it's reasonable to consider a tag immutable, though you should always checksum if you do.

Re: Picturing Git: Conceptions and Misconceptions

#20

Post by kubanczyk »

bironran wrote: post #17
kubanczyk wrote: post #13

Earlier quoted context omitted.

2. Tags are named, mutable pointers to commits. 3. Branches are named, mutable pointers to commits, that you can "ride". While you "ride" a branch it keeps moving to always point to your latest commit. 4. HEAD is an implicit branch that you "ride" at all times.

afaik, the commit a tag points to is immutable unless you delete and recreate (and then nothing is immutable really). re "ride" - that's exactly what I'm trying to avoid. It's an additional concept that isn't needed to understand Git. You need to understand the model. The "ride" is an emergent property of the model and commands that you eventually understand, but not a core part.

Without the concept of "riding", terms "tag" and "branch" would become exact synonyms. In that case you can just remove point 2 (consider it just a syntactic sugar) and thus simplify your list.

If a tag has any attempt at immutability at the data structure level, I know nothing of it.

Post reply on HN