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

141–150 of 281 posts

Re: Git Branches: Intuition and Reality

#141

Post by chihuahua »

intrepidsoldier wrote: post #126

Anything about Git reminds me of this: https://youtu.be/EReooAZoMO0?si=sHqcYsf8v6LyWLAx

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

It's not quite in "a monad is just a monoid in the category of endofunctors" territory, but when this many smart people have difficulty understanding something, I think Git is to blame, not the people.

Re: Git Branches: Intuition and Reality

#142

Post by ajross »

layer8 wrote: post #135
ajross wrote: post #134

Earlier quoted context omitted.

> a path that in general can’t be reconstructed from the information Git keeps. Uh... yes it can. Commits have a list of 0 or more parents. That creates a DAG. There are literal hordes of tools out there that reliably interpret this, from visualizer tools to practical mutators like git bisect. Maybe you're trying to say that no single commit order exists that traverses the whole tree. That's true, because branches ca…

That’s not what I was saying. I was referring to the history of branch tips.

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 trying to explain it as "git doesn't store enough information" to construct that spanning path seems confused to me. It's not about what git stores, it's just math: there is no such path in the general case, period.

Re: Git Branches: Intuition and Reality

#143

Post by chihuahua »

ndriscoll wrote: post #111
mwexler wrote: post #27

Earlier quoted context omitted.

I guess. To me, the opposite is a more worthy essay: why, with all the power to customize our tech, do we create things that consistently work differently than people's intuition? The fact that it "mostly jibes" feels like a footgun, not a feature. I get that for some, "git just works! It made sense from day one" but in my limited experience, 0% of people I've worked with have said that. Sure, we can all learn the te…

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?

Re: Git Branches: Intuition and Reality

#144

Post by chihuahua »

marcosdumay wrote: post #119
mwexler wrote: post #27

Earlier quoted context omitted.

I guess. To me, the opposite is a more worthy essay: why, with all the power to customize our tech, do we create things that consistently work differently than people's intuition? The fact that it "mostly jibes" feels like a footgun, not a feature. I get that for some, "git just works! It made sense from day one" but in my limited experience, 0% of people I've worked with have said that. Sure, we can all learn the te…

Often, people's intuition is wrong on very important ways, and something that works like they expect is sure to create footguns or just blow up by itself. But I'm not sure git is a case of this. The DVCS that were created following people's intuitions were known to be slow and internally complex, but I have never heard about them failing. (And the slowness is obviously of a kind that can be optimized away.) We just s…

I totally agree with it being "the worst UI ever devised". It's fine to use commits with parent pointers and branches as pointers to commits and all the other stuff internally. But there should be a UI wrapped around that that maps to operations that make sense for the purpose of working on a software project.

Not this:

git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [--no-verify] [-s ] [-X ] [-S[]] [--[no-]allow-unrelated-histories] [--[no-]rerere-autoupdate] [-m ] [-F ] [--into-name ] [… ]

Re: Git Branches: Intuition and Reality

#145

Post by layer8 »

ajross wrote: post #142
layer8 wrote: post #135

Earlier quoted context omitted.

That’s not what I was saying. I was referring to the history of branch tips.

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.

Re: Git Branches: Intuition and Reality

#146

Post by CuriousCosmic »

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

Re: Git Branches: Intuition and Reality

#147

Post by cedws »

samus wrote: post #31
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.

Protecting branches is indeed very important. I make errors all the time when screwing around. It helps enormously being restricted to just messing up one's feature branches. Many other changes can be done via the GUI with PRs and the various kind of controlled merge and rebase strategies they support, like Merge, Rebase + Merge, FF-only Merge, Squash merge, etc.

It's also a security feature. If you have a repo with a lot of developers working on it, you need to be sure they absolutely cannot slip in code with nobody noticing, or trigger CI/CD and compromise build secrets or even production.

Re: Git Branches: Intuition and Reality

#148

Post by karatinversion »

Sharlin wrote: post #21

But... If you have a rebase workflow, then `git checkout trunk; git rebase branch` is exactly how you "merge" an offshoot branch into a trunk branch! That's what Github does when you rebase-merge a PR, for example.

No, that’s not right. If you did that, you would need to force push to get the result pushed to the remote.

Re: Git Branches: Intuition and Reality

#149

Post by CuriousCosmic »

chihuahua wrote: post #141
intrepidsoldier wrote: post #126

Anything about Git reminds me of this: https://youtu.be/EReooAZoMO0?si=sHqcYsf8v6LyWLAx

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 guides for all the things you need to do.

So it always hurts me when I see people ranting and raving about how awful git is, how it can't do x, or how it doesn't make sense how it works but then you send them the guide or tutorial hosted on the git-scm website and suddenly it makes sense.

Not to be beating the RTFM horse but RTFM guys.

Re: Git Branches: Intuition and Reality

#150

Post by [deleted] »

parasti wrote: post #83

The article goes in the right direction, but from a weird starting point. Saying things like "a branch contains the entire history" just adds to the general confusion about Git. Git does not have branches. Sure, Git emulates branches to appear familiar and intuitive, but it is actually counterproductive to use that as a starting point to explain how Git works. Git manages a graph of commits and some of those commits…

[deleted]
Post reply on HN