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

Git Branches: Intuition and Reality

jvns.ca

Post reply on HN
Print view View original

181–190 of 281 posts

Re: Git Branches: Intuition and Reality

#181

Post by astrobe_ »

alex_smart wrote: post #156
tremon wrote: post #140

Earlier quoted context omitted.

git reset --hard is actually dangerous, because it throws away local modifications that were not yet committed. To undo just the commit and not the work, you should use git reset --soft (to undo just the git commit) or git reset --mixed (to undo both the git commit and the "git add"s leading up to the commit).

git checkout will also happily throw away local unstaged modifications, and I would argue that it is even more dangerous because I did not have to type "--hard" to shoot myself in the foot.

There must be something you do terribly wrong if you believe it happened to you in normal use.

Re: Git Branches: Intuition and Reality

#182

Post by dayjaby »

TeMPOraL wrote: post #128
mr_mitm wrote: post #121

Earlier quoted context omitted.

When the entire structure of commits is called a tree, I find the name "branch" fitting. The branch is identified by its head commit, so the path from head to root is uniquely defined and that's the branch. (Disregarding merges for now.)

> Disregarding merges for now. Without disregarding them, it's not a tree, but a DAG.

It is a tree. What makes you think it's just a DAG? Are there commits with multiple parent commits or what?

Re: Git Branches: Intuition and Reality

#183

Post by imron »

dayjaby wrote: post #182
TeMPOraL wrote: post #128

Earlier quoted context omitted.

> Disregarding merges for now. Without disregarding them, it's not a tree, but a DAG.

It is a tree. What makes you think it's just a DAG? Are there commits with multiple parent commits or what?

Yes. Merge commits have two parents.

Re: Git Branches: Intuition and Reality

#184

Post by zaphar »

dayjaby wrote: post #182
TeMPOraL wrote: post #128

Earlier quoted context omitted.

> Disregarding merges for now. Without disregarding them, it's not a tree, but a DAG.

It is a tree. What makes you think it's just a DAG? Are there commits with multiple parent commits or what?

There absolutely can be. Merge commits have multiple parent commits for example. It's definitely a graph not just a tree.

Re: Git Branches: Intuition and Reality

#186

Post by imron »

skrebbel wrote: post #101
riperoni wrote: post #44

While the explanation is right in some sense, it misses a few points. Branches are pointers to a commit and that pointer is refreshed when a new commit is created. One could say they are a wandering tag (without explaining a tag for now). The actual chain of commits that represent what we see as branch comes from the commits themselves. Those commits point back to their parent commit. And then one can see why no bran…

For years I was deeply annoyed by the terrible name “branch” for something that acts more like a bookmark (or “wandering tag” indeed!). And then I learned that git branches are branches in exactly the same way that the first element of a linked list in C “is” the linked list. Git was made by C people and they’re used to referring to entire data structures by way of some root element. I mean that doesn’t make me disli…

> Git was made by C people

This is why I think of branches as pointers. The file contents are literally just a pointer to a commit on the DAG.

Re: Git Branches: Intuition and Reality

#188

Post by [deleted] »

skrebbel wrote: post #101
riperoni wrote: post #44

While the explanation is right in some sense, it misses a few points. Branches are pointers to a commit and that pointer is refreshed when a new commit is created. One could say they are a wandering tag (without explaining a tag for now). The actual chain of commits that represent what we see as branch comes from the commits themselves. Those commits point back to their parent commit. And then one can see why no bran…

For years I was deeply annoyed by the terrible name “branch” for something that acts more like a bookmark (or “wandering tag” indeed!). And then I learned that git branches are branches in exactly the same way that the first element of a linked list in C “is” the linked list. Git was made by C people and they’re used to referring to entire data structures by way of some root element. I mean that doesn’t make me disli…

[deleted]

Re: Git Branches: Intuition and Reality

#189

Post by ptx »

seba_dos1 wrote: post #132
layer8 wrote: post #129

Earlier quoted context omitted.

As you say, commits link to their parent(s), and those links effectively represent the edges of the commit graph. It makes perfectly sense to record moves on those edges. That’s how other VCSs do it. There is no conflict with the commit model. Viewing the commit graph in terms of nodes (commits) or edges (diffs) is equivalent, these are dual views you can easily convert between. The internal representation is indepen…

What I meant is that git doesn't have any structure to represent an edge other than a simple pointer. Conceptually it wouldn't be a big change to add some, but the consequence of that is that everything in git revolves around nodes rather than edges, and whenever the concept of an edge is needed (such as in "cherry-pick") it's being calculated on fly.

If you think of it not as a "rename" (which would belong in the edge object if it existed) but rather as a "note: the file A in this tree was known as B in the parent tree" it would make perfect sense to store it in the child commit.

Re: Git Branches: Intuition and Reality

#190

Post by xorcist »

seba_dos1 wrote: post #90
jansan wrote: post #71

Earlier quoted context omitted.

This was the most useful piece of information that I have ever read about Git. But what happens if you merge branch A into beanch B? A and B will both contain the commits of A, but in B there may be commits of B between the commits that were merged. Do the same commits of A then have different parents depending on which branch they are on?

> Do the same commits of A then have different parents depending on which branch they are on? Absolutely not. Commits are immutable (representing whole repo state, not a diff), and branches are just (mutable) pointers to them. As the sibling already noted, a merge commit is just a regular commit. It simply points to multiple parents, "merging" them. Aside of the whole machinery to resolve conflicts etc. that's pretty…

> Commits are immutable (representing whole repo state, not a diff)

To make things more clear: Repo state here is the contents of all files, and some metadata including a pointer to the previous commit.

So a commit hash uniquely identifies not only a set of files but the unique history leading up to it! That's why we some people like to call git the original block chain (there's no proof of work involved of course so it can never be used for payments or anything like that, but the merkle tree bit is similar enough).

Post reply on HN