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

161–170 of 281 posts

Re: Git Branches: Intuition and Reality

#161

Post by lifeisstillgood »

layer8 wrote: post #59
mtnygard wrote: post #29

I have found that git makes a lot more sense if you reverse the mental model of lineage. People think about a lineage going forward . But a more useful way to think is in terms of backward pointers. A commit points to it's parent(s). Since a branch is just a commit ID, you can follow the parent links backwards to find the whole history of that branch. So a "branch point" is just where two chains of parent links conve…

The issue is that if you consider a branch to be what is really the history of the branch tip, then a branch is not just the part starting from the last join with another branch. Instead it is some directed path through the commit DAG, a path that in general can’t be reconstructed from the information Git keeps. If, for example, you have a structure like | o / \ o o A | | B o o \ / o / \ o o C | | D o o \ / o | then…

Just to go off on a tangent - that's a pretty neat diagram for a throw away comment. was that just careful spacing in the HN textbox or did you use a tool - which one ? :-)

Re: Git Branches: Intuition and Reality

#162

Post by skrebbel »

mr_mitm wrote: post #121
skrebbel wrote: post #101

Earlier quoted context omitted.

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…

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.)

FWIW “tree” has a specific, different meaning in Git. It’s a file tracking the contents of a directory.

Re: Git Branches: Intuition and Reality

#163

Post by forrestthewoods »

CuriousCosmic wrote: post #149
chihuahua wrote: post #141

Earlier quoted context omitted.

Given how many smart people are confused by Git, and how many times Git's behavior needs to be explained in a way that often raises as many questions as it answers, it seems to indicate that Git's model is not at all intuitive and doesn't map well to how people generally use it to get work done. These are all people who have no problem understanding all kinds of other technologies and building complex systems from th…

I have to serious ask. Of the people who have issues with using or understanding git, how many of them have actually read the docs? Git is by no means perfect but the development community is great and there is a massive focus on improving the project and making things more approachable and intuitive. And because of that, git actually has really solid, coherent documentation with easily digestible tutorials and guide…

Git makes version control roughly 10x more complicated than it needs to be.

I can teach an artist or designer who has never heard of version control how to use Perforce in roughly 5 minutes. They will never blow off their leg and will likely never lose work. It will probably be a few months before they hit some edge case where they need help.

Git requires building a non-trivial mental model. Then it requires memorizing a whole bunch of unintuitive commands with unintuitive flags.

> Not to be beating the RTFM horse but RTFM guys.

Good tools are intuitive and can be incrementally learned without resorting to dense documentation.

RTFM is definitely a solution. But when a very large number of users have consistently similar issues at some point you have to stop blaming the users and admit the tool isn't easy to learn.

Re: Git Branches: Intuition and Reality

#164

Post by ndriscoll »

CuriousCosmic wrote: post #146
rkangel wrote: post #18

Git doesn't have the concept of "main is special", but at least tools like Gitlab have protected branches to stop you screwing up too much. Some concept of "parent" and "child" branches would actually be pretty interesting. You do have to support multiple "parent" branches though for long term support branches.

It actually does but it's very much in alpha/active development (under the umbrella of OpenSSF with the intent of being integrated into mainline git eventually). https://github.com/gittuf/gittuf

Git itself doesn't run a persistent process and I don't see how it'd make sense to prevent a user from making arbitrary changes to their local repo, so this sounds like just another server like GitHub, Gerrit, Gitlab, etc. that already have those features.

Re: Git Branches: Intuition and Reality

#165

Post by afiori »

MauranKilom wrote: post #60

I don't use git at work, but in my private hobby projects my friends usually get mad when they watch me juggle changes and branch pointers with git reset --hard and git stash... How do you undo a merge that you didn't mean to do/did wrongly? git reset --hard Have some cosmetic fixups on your local branch that really should go into main (or a separate branch) first before merging a bigger feature? git stash git checko…

I agree that git is almost asking you to juggle commits.

My preference is to use temporary branches and cherry-picking instead of stashing; I mostly use a gui* to work with git so it is easy to select the two or three commits to cherry-picking or see visually if an interactive rebase would work.

* https://gitextensions.github.io/

Re: Git Branches: Intuition and Reality

#166

Post by afiori »

int0x80 wrote: post #133
zaptheimpaler wrote: post #120

Earlier quoted context omitted.

Both of those sound totally reasonable to me! I don't know of any better ways to do that stuff and there's nothing risky about it.

One thing that is risky about git reset --hard is that any non-committed changes are lost. That has bitten me a few times.

My controversial opinion is that git needs some kind of gui that help you keep track of the state of the repo

Re: Git Branches: Intuition and Reality

#167

Post by ajross »

layer8 wrote: post #145
ajross wrote: post #142

Earlier quoted context omitted.

But that's not related to the DAG at all. The branch can be changed at any moment for any reason to point to any commit with any content. But it's true that conventionally, a new branch tip should always have the previous branch tip as an ancestor. But not always as a direct parent, and even if so it might be a merge commit that joins two different branches. There is indeed no single spanning path through a DAG. But…

The fact that the branch tip can be moved to unrelated commits is another issue with Git’s model, and a mismatch to the intuitive “a named lineage in the DAG” conception of branches. In other VCSs, that would be a new/different branch, and you could still rename branches so that the same name will later refer to a different branch, but the branch history as such (including renames) would be preserved.

> mismatch to the intuitive “a named lineage in the DAG” conception of branches

Once more, that conception may be intuitive but it is wrong. A branch is emphatically NOT a line through the DAG, it's the whole DAG. There simply is no single list of patches to apply to get from one commit to another, even if both were at some point heads of the same branch, and even if one is an ancestor of the other.

And the reason it's wrong is that branches can merge together. You can have commit A descended from both the "main" branch and the "topic_a" branch, despite the fact that those two had diverged. This isn't a bug, it's a feature. You don't have to use it if you don't want to (lots of projects require linear commit histories in their main branch), but it's part of the tool nonetheless because some projects (Linux especially) use it heavily and to great effect.

Re: Git Branches: Intuition and Reality

#168

Post by afiori »

chihuahua wrote: post #143
ndriscoll wrote: post #111

Earlier quoted context omitted.

As one of those people that thinks it's extremely intuitive, I have to wonder where the confused people are learning about git. The documentation on the site[0] is quite clear: > A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you start making commits, you’re given a master branch that points to the last commit you made. Every time you comm…

If Git was "extremely intuitive", and the documentation was "great", why would so many otherwise smart people keep writing blogs about it with incorrect diagrams? What is your theory about why so many people are having difficulty creating a correct mental model about Git, and why so many people are writing incorrect blogs about it?

In part it is because git is hard to use, in part it is because mostly people learn git by oral tradition and often treat it like sorcery.

Re: Git Branches: Intuition and Reality

#170

Post by Feathercrown »

CuriousCosmic wrote: post #149
chihuahua wrote: post #141

Earlier quoted context omitted.

Given how many smart people are confused by Git, and how many times Git's behavior needs to be explained in a way that often raises as many questions as it answers, it seems to indicate that Git's model is not at all intuitive and doesn't map well to how people generally use it to get work done. These are all people who have no problem understanding all kinds of other technologies and building complex systems from th…

I have to serious ask. Of the people who have issues with using or understanding git, how many of them have actually read the docs? Git is by no means perfect but the development community is great and there is a massive focus on improving the project and making things more approachable and intuitive. And because of that, git actually has really solid, coherent documentation with easily digestible tutorials and guide…

I've read the docs. Too much explanation of command line flags, not enough practical examples. It is thorough though.
Post reply on HN