17 ms·

Git branches are named sequences of commits

170 points by EamonnMR 4y ago

hedora 4y ago
A ref is a pointer to a node in an directed acyclic graph, and a branch is a pointer to a ref. Not all subgraphs of directed acyclic graphs are sequences. So, not all branches are sequences.
p-e-w 4y ago
I wish we had a version control system that can be used without worrying, or even knowing, about its technicalities and implementation details. Working with Git for version control is as if your photo management tool required you to learn about inodes and b-tree superblocks in order to save a JPEG file. I just want to keep source code history, and allow multiple people to collaborate on the same project. I don't want to know anything about "refs" or whatever else is happening behind the scenes, yet it appears Git can't be used unless you are (at least occasionally) willing to look at the plumbing layer.
- cratermoon 4y ago
  If there's a UI, or even a CLI, that properly matches the conceptual model of development with git, I'm not aware of it. I'm sure there's a much clearer user-centric model of work struggling to get out from underneath the implementation details. Over the years of working with git I've gradually learned bits of the plumbing underneath the porcelain, but reluctantly.
- graypegg 4y ago
  Version control feels like it does require some complexity though. I think we all like to imagine that all it does is stores changes per file, wrapped in commits. But when you add requirements like merging other people’s work with yours, movable “tags” to mark named versions, and the sort of cut/splice/move around operations you will always need because you accidentally did something you shouldn’t have… I think you end up rebuilding most of Git’s plumbing.
  - p-e-w 4y ago
    Video codecs are also complex (actually, they are almost unimaginably complex). But I've never seen a smart TV telling the user something about "lapped transforms" or "chroma subsampling". I'm a user of Git. Why do I have to learn about implementation complexities in order to fix problems that arise from normal version control operations? I can't think of any other software that forces me to do this. Even compilers (at least those for mainstream programming languages) don't require me to understand their AST representation or other details of how they work internally.
    - taeric 4y ago
      Televisions absolutely do this for power users. Or give them terrible image quality for regular users.
    - graypegg 4y ago
      WildBit had a really cool project a while ago called Conveyor. [0] It’s a shame it never took off. It was built on git, but hid the complexity of branching + other git things behind “tasks”. You’d start a task, and silently push that branch out to everyone. It’d silently merge things in the background and handle a lot of the chores you have to do with git rebasing and such to keep branches mergeable. It failed miserably with us because it perpetually created impossible to solve git issues. Someone accidentally removes a gitignore file and commits a config file with a password? Your SOL. It will keep coming back because it will exist on at least one other person’s device which will get force pushed back to the repo. The weird plumbing exists because version control is hard, and prone to humans throwing wrenches into its nominally perfect system. The real reason you don’t remember every magic git incantation is because you normally only need a specific one, once a year. But it has to be there! [0] https://web.archive.org/web/20190226201600/https://conveyor.com/ https://web.archive.org/web/20190226201600/https://conveyor....
    - theamk 4y ago
      TVs are consuming devices. If you are only wishing to consume git, you need to know "git clone" and "git checkout", and that's it, no need for internals. Or manybe not even that, you need to know where "download" link on Github interface is. If you are encoding video, you often need to know about chroma subsampling, and colorspaces, and fractional framerate and all the other absurd technical details. It is actually much worse than git. You can avoid those technical details if you use high-level software, only stay on happy path, and avoid any complex operations. You'll take longer and produce worse quality output than if you had fully mastered the software -- but often this is OK. This is true both for video encoding and for git.
- rjbwork 4y ago
  We do, at least to my mind. It's called Mercurial. It's great, extremely close to git, but is much easier to use IMO. It's really a damn shame that git won - primarily, I think, due to the cachet of its author.
  - dilyevsky 4y ago
    The way I remember it git one for two reasons: 1. hg was (maybe still is?) much slower 2. “No technology can ever be too arcane or complicated for the black t-shirt crowd” (fake Linus’s words not mine)
    - gregjor 4y ago
      I think you’re quoting me. Thanks! https://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and-git https://typicalprogrammer.com/linus-torvalds-goes-off-on-lin...
  - bigDinosaur 4y ago
    Either way, is Git actually that hard to use? You can learn about 10 commands and develop any software just with those. I have no illusions about it's gnarly aspects but also just don't find it particularly difficult. Contrast a programming language that might have footguns in just printing strings.
    - photonbeam 4y ago
      Git is a pain to provide support for if you’re an internal tools team, lots of users with incorrect mental models
  - shanev 4y ago
    Close. It won because of Github. Git was gaining over SVN slowly but it was Github that really propelled it into widespread use.
- Agentlien 4y ago
  Why do you feel you need to know these details? I used git actively without issues for years before I took the time to learn how it works under the hood. While understanding the details was fun and helpful, I can't say it really changed much about how I use the tool.
- bad_username 4y ago
  Linus built an incredibly elegant and simple underlying model for git. For what it successfully does - distributed version control - it is remarkably simple and easy to grasp if you want to. However, this model was not mapped well to the high level concepts that the typical user of a VCS operates in. This is the biggest issue of git: it's hard to make sense of it by its UI if you do not understand how it works under the hood. I struggled until I read the pro git book. I wouldn't go as far as to compare this to knowing about filesystem data structures for saving a jpeg file. It's more like using an old school file dialog where you just see the bare file system and you need to know your way around your drive.
  - josephg 4y ago
    Git's other (compounding) problem is how the CLI is an inconsistent mess. Why do you create a branch via the "git checkout" command? Why do you delete tags using "git tag -d" but delete stashes using "git stash drop"? If you want to blow away local uncommitted changes, you can use "git reset", "git reset --hard" or "git checkout (file)" - which (I think) all do totally different things. Git's data model may be elegant, but its hard to appreciate it through the tangled mess of git command line options.
    - Nadya 4y ago
      I use Git daily and literally couldn't tell you how to use it because I've aliased every single command it has. I basically have a wrapper over it and to teach anyone how to use Git I have to peel my layer away and check what I have things aliased to. It feels like terrible ad hoc user design built over an otherwise extremely elegant and clean data model.
      - freetonik 4y ago
        Would you mind sharing your aliases? Curious to see a different mental model.
    - amadvance 4y ago
      They tried to fix that mess, like with the recent git switch/restore. But it looks like it was too late.
- taeric 4y ago
  You've clearly never tried to save raw image files from a mid level camera. :) heaven help you if you try a newer camera than your os. I will make no major defense of git, but I am intrigued at the level of difficulty reported about it, compared to the obviously higher level of use that it gets.
  - ansgri 4y ago
    What kind of cameras and difficulties are you talking about? It’s almost always just a DCIM folder on the sd card. Videos, OTOH, are stored rather arcanely, at least on my Sony, with separate directory structure for each format.
    - taeric 4y ago
      Newer cameras have had raw formats that were not supported right away. Cr3 being the one that bit me recently. I think most software has caught up. But it did catch me off guard that my machine needed updating to support this. I also think flatpak had some trouble with it. Can't remember details.
      - ansgri 4y ago
        Ah, you're talking about actually using them, not just saving :)
        taeric 4y ago
        Little of both. Took me a few tries to get them recognized as pictures. Rather frustrating experience, all told.
- seba_dos1 4y ago
  "refs" are not behind-the-scenes things, they're the things you want to operate on. It wouldn't be like having to learn JPEG superblocks, it's more like learning what a pixel is. You need to understand Git's data model, not its plumbing. No VCS will be useful for anything that isn't trivial if you don't understand its data model.
  - Gunax 4y ago
    I disagree. We shouldn't have to know how a branch or commit is stored. Whether git interally makes a new ref, copies everything to a new directory, or does some hashing magic doesn't matter to the user. I agree that we end up needing to know about refs because of git's user interface, but I consider that a flaw or limitation.
    - seba_dos1 4y ago
      It's not about "how a branch is stored". We're not talking about objects, packs, blobs or any other stuff I never actually had to learn about while using git. We're talking about refs - the primary way for users to reference commits and other things in git. Just about every command you use takes refs as arguments. It's essential to even just imagine the state of the repository in your head. It's what the first tutorial you read about git should explain to you.
- aaronbrethorst 4y ago
  There's something funny to me about the idea that the user-level Git commands are called the "porcelain," as if they were a toilet. https://stackoverflow.com/a/6976506 https://stackoverflow.com/a/6976506 unrelated: I wish people would stop insisting on using full-width columns to display their blog content because it is nearly impossible to read on a 27" monitor. Wrap that blog content with a <div style='max-width: 65ch'>
  - thiht 4y ago
    > I wish people would stop insisting on using full-width columns to display their blog content because it is nearly impossible to read on a 27" monitor. There's a noticeable portion of tech people who seem to believe that unused screen space is somehow wasted. No margins + no line breaks is the gold standard to them. I don't get it, it's unreadable to me.
    - phist_mcgee 4y ago
      Dan Luu is famous for this. I can barely read the page it's so harsh. eg. https://danluu.com/futurist-predictions/ https://danluu.com/futurist-predictions/
  - drdec 4y ago
    You don't have to run your browser maximized you know
    - aaronbrethorst 4y ago
      Please tell me about how you will replace me with a very small shell script next.
    - phist_mcgee 4y ago
      Telling someone to change their workflow because a website refuses to deal with larger screen sizes is silly.
      - 4y ago
- thunderbong 4y ago
  That's why we use fossil [0]. It just gets out of the way. It has its own server, wiki, ticket system and now, even chat! The main complaint I see here is that it doesn't have rebase, and my point is the goal of the code is for the product to work, not to have a beautiful commit graph. I've used CVS, SVN, Git. But nothing comes close to the usability that fossil provides. [0]: https://www.fossil-scm.org/ https://www.fossil-scm.org/
  - vbezhenar 4y ago
    Beatiful commit graph allows to actually understand commit history. I dread opening history with merges. It's always incomprehensible mess for me.
- somat 4y ago
  I use the heck out of fossil and have little idea how it works underneath. I consider fossil the gold standard for a good versioning system ui. I don't think git has any excuse for being as weird as it is. fossil init repo; make a new fossil repository fossil open repo; open a fossil repository somewhere fossil add file; note: very different than git add. in fact I was very confused by git add, in fossil the repository knows what files are managed by it and there is no staging area. so you only use "fossil add" when adding a new file. If you move a file use "fossil mv" to let fossil know what you did. Along with "rm" when you remove a file. The staging area still feels like an unnecessary added bit of friction. fossil commit There are others I use often "merge", "sync", "revert" but they tend do what the command appears to do. Speaking of revert, the git equivalent is really strange , even among the rest of the strange git ui. Shit! I messed something up and want to revert back to the last committed change, easy, just run the command "git reset --hard HEAD"
  - KRAKRISMOTT 4y ago
    The bad thing is that fossil allows the upstream to make destructive changes to client's copy of code. That's a big no no.
    - owyn 4y ago
      Until you need it. :)
    - somat 4y ago
      So does git, in fact, without a better explanation of what exactly you mean, I would say upstream making changes to the the clients code is the core useful property of a version control system.
  - osigurdson 4y ago
    git init . git add file git commit -am "my message" Pretty simple really. You don't need to think about staging if you don't want to.
    - dataflow 4y ago
- kaba0 4y ago
  People mention previous gen version control systems in sibling comments, but git quite clearly “won” against them. A more useful outlook would be looking for what the next gen VSC might be, which would be Pijul and alia (where diffs/patches are applicable in any order, so merges will be trivial, no more merge strategies), and if they do get production ready they might really provide a better UX/more intuitive mental model for the programmer.
- ozim 4y ago
  My view on it is that unfortunately there is no way to do that. Some things are going to be hard and that is it, you cannot make it easier. We see that in never ending stream of frameworks or "new/better/easier" ways which in the end become bloated in the same ways as most other stuff because problems don't go away if you don't know about them. In the end data model of git is its killer feature because it gives me tools to deal with hard problems and do it efficiently.
  - comfypotato 4y ago
    I always feel that complaints like the one you’re replying to aren’t thought through. The simple follow up is: how would you do it better? There’s no better way. You only need to look at the complicated part of git for very complicated things. If you think about it, commits and branches are incredibly simple relative to what’s actually happening (when it comes to working with them, that is). Listening to old folks talk about pre-git version control gives me appreciation for just how good it is.
    - OkayPhysicist 4y ago
      There are a few fixes I would make, but only a handful would be significant to everyday usage, none would involve fundamentally changing the underlying data model. The biggest would probably be to make all commits required to be made onto branches and either embed the data of what branch created a commit into the commit itself, or have a separate data store of branch-to-commit info, which would allow for "branches as a series of commits" to be a first class citizen besides "branches as references to a commit". Maybe add git notes-esque support for editable metadata on the branch, where you could put information that currently would be stored in some pull request management system.
      - comfypotato 4y ago
        The data regarding what branch a commit was made is available. It’s all available if you dig deep enough. What you’re talking about sounds like the work of a git visualization tool made for fixing problems. I do love a repo viz where I can see the tree of branches for helping me understand where something went wrong. The surface level stuff people use day to day is as simple as it needs to be.
- xorcist 4y ago
  All abstractions leak. You cannot work your jpeg photo collection but opening, editing, saving, editing, saving, editing, saving and then blame your tools when your jpegs are blocky and ugly. First you have to know some basics about lossy compressing and destructive editing. Then, you can understand what steps you really want to take. It's the same with version control systems. With git, first you have to understand what a commit and a branch is. Then, you can work.
- OkayPhysicist 4y ago
  It's version control for software developers, who simultaneously need all the power it provides, and ought to have the educational background to understand directed acyclic graphs. Complaining that git is too complicated because it requires basic knowledge of DAGs is like complaining that your word processor is too complicated because it assumes a proficiency in written language.
draw_down 4y ago
It’s not helpful to say branches are only refs as a way of arguing branches don’t exist. But it is helpful in understanding how they work, what it means to pass a branch argument to git for some operation. When I understood the reflog and how nothing I do is really gone (just gotta find it!), that was when I realized how much I like git.
- littlestymaar 4y ago
  > When I understood the reflog and how nothing I do is really gone (just gotta find it!), that was when I realized how much I like git. The reflog won't help you recover things in the staging area that where accidentally `reset --hard` though … (you can still get the ones you added to the index with `git add` but not committed[1], but changes that weren't added are lost for good) I love git, but the UX is still terrible … [1]: https://stackoverflow.com/questions/7374069/undo-git-reset-hard-with-uncommitted-files-in-the-staging-area https://stackoverflow.com/questions/7374069/undo-git-reset-h...
  - draw_down 4y ago
    [dead]
  - buck4roo 4y ago
    Why do you love it? It looks like you've described a tool with 1) a terrible UI, and 2) trains users to use commands that will eventually cause them to lose unsaved work.
    - littlestymaar 4y ago
      1. git has a terrible UX (not UI), including destructive actions without warning and much more really cumbersome things for newbies to learn about 2. once you know it enough, git is a powerful tool that I really appreciate. 1. and 2. aren't contradictory. And I would love git even more if the UX wasn't the dumpster fire it is, but I happen to know enough of its bad UX to be able to do what I want with it. Also, unlike the average git expert on HN, I still recognize that the UX is shit, and that you should need to spent as much time as I did in order to be able to use it at all. I'm really annoyed when people argue that a bad UX is in fact good because of some elitist reasoning.
cybrexalpha 4y ago
> It's true that Git implements branches as refs, plus also a nebulous implicit part that varies from command to command. But that's an unfortunate implementation detail, not something we should be committed to. I actually find git way easier to understand if I don't think about branches in the way the author suggests. My mental model for git really is commits and refs, and it helps me use it fluently. When I wave my hands around and say "a branch is nothing but a ref" what I actually mean is "...and so you should understand how it actually works, so what I'm about to do doesn't look like magic".
- Gunax 4y ago
  I think you and the author are right, but addressing different audiences. I think most people come to git with their own mental model of what a branch is, what a merge is, etc. Learning git is often mostly undoing their preconceptions (ie by saying 'a branch is just a ref'). But ultimately, we humans tend to think of a branch as a branch, not a ref. For instance, the previous sentence probably made perfect sense to you.
  - topaz0 4y ago
    I agree, and would add that this is exactly what the OP is saying when it talks about this being a communication issue. Saying "a branch is just a ref" is the right attitude for talking to git and making it do what you want it to do, but it's the wrong attitude when you are writing or talking about code, in which case branches are the reification of the processes by which your code evolves.
  - edflsafoiewq 4y ago
    Do they? I certainly had no intuitive notion of how version control would work before I learned git for the first time.
    - Name_Chawps 4y ago
      You did have an intuitive notion of what the word "branch" means, though.
brianpan 4y ago
I'd argue that there's a difference between a git branch (an implementation detail) and a development branch (a process feature) and that's the difference the author is running up against. Are you teaching someone about development? Or teaching about git? Because a git branch IS a ref. And a git branch is useful because it points at a commit in a series of commits. Branches and commits are slightly different concepts depending on your VCS and it can be worth understanding the details.
_ZeD_ 4y ago
[insert obligatory mercurial comment here]
xvilka 4y ago
This is why there is a hope to build a new VCS that isn't that state-dependent and based on isolated patches - Pijul[1]. [1] https://pijul.org https://pijul.org
seba_dos1 4y ago
> None of these can be understood if you think that a branch is nothing but a ref. To the contrary - all of these can have "branch" changed to "ref" and they still make perfect sense. "ref" is just as much a sequence of commits as "branch" is. Every commit is.
paweladamczuk 4y ago
I'm pretty sure every person who says "branches are nothing but refs" understands why they are called branches. They just want you (and others) to learn. This is an important piece of puzzle that many people miss. Would you sacrifice all those (other people's) learning opportunities just so that you don't get annoyed?
- deleted 4y ago
  [deleted]
vhab 4y ago
The comments in this thread are very interestingly making the Author's point. Yes, you can be "technically correct" saying branches are just refs, but it's not a useful statement for most users. I believe the author makes a very valid point, and we could do with a bit less "technically correct" and more with language targeting the usage rather than technical implementation. Git is confusing enough for many people, and we don't have to make it more confusing for them.
- metafunctor 4y ago
  I'd argue git is confusing for many people because they don't understand the data model. The solution is to learn the basic data model instead of pretending that "a branch is a ref" is not true. Because it is true.
  - coldpie 4y ago
    For anyone reading this who would like to learn about the data model, I highly recommend following along the "gitcore-tutorial" manpage. Like actually type the commands and play around with the results. Once you understand what's going on under the hood, the UI commands all make intuitive sense.
  - jameshart 4y ago
    A branch is not a ref. A head ref is a ref that names a branch. But branches can exist in git without refs. Branches are artifacts that exist in the commit DAG - they are dangling chains of commits that end without being merged in to some other commit. They exist, as pure platonic branches, even if they are un-referenced. But then you can make a head ref and name one and now all of a sudden you have a named branch. As you make more commits that extend the branch while ‘attached’ to that head, the head ref follows the tip of the branch (that is in particular a thing a head ref does that a tag ref does not). But you can add commits and extend a branch in a detached state of you like - no head refs following the branch tip. Yet the branch definitely exists. And then if you tag it, you name it. So no, I don’t think “a branch is a ref” tells the whole story.
    - 4y ago
abstrakraft 4y ago
OP argues that branches aren’t “just refs”, they’re a sequence of commits. I’d argue that a ref _is_ a sequence of commits. (Or, to be pedantic, it uniquely identifies a sequence of commits.)
- deleted 4y ago
  [deleted]
- _cenw 4y ago
  A commit contains a sequence of commits, in fact (unless it is the root commit). So a ref is just a single commit, which then contains parent commits. The branch model really falls apart if you ever do a more complex merge or rebase.
davidw 4y ago
git branches are just a monoid in the category of endofunctors. Did I get that right?
dataflow 4y ago
I feel like I have a bigger problem with "a sequence of commits" as a phrase than I do with whatever he wishes to call a branch. A commit itself is a sequence (it includes its own history!), so a sequence of a sequence is a confusing thing to talk about without any sort of qualification, since they're heavily constrained by being linked together. Moreover, what he's calling a sequence is really a DAG; it's not linear. Hearing "a sequence of commits" is so jarring that it conveys more confusion about git than anything else... perhaps that's why he gets corrected so often? But in terms of what a branch is, if you don't want to call it a "ref", then I'd just say it's a commit symlink?
- LegionMammal978 4y ago
  Hmm, I think you'd be going a bit far by calling each commit a sequence. A commit does not contain its parent commits: it only contains pointers to its parent commits. By that logic, a linked list isn't a sequence of nodes, since each node is itself the head of a sublist.
  - dataflow 4y ago
    The pointer isn't really relevant to what I'm sharing. I'm talking about what it is logically, not how it might be represented physically. You could certainly make each commit contain the other one physically if you wanted to represent it that way in some programming language. Of course there's not much of a reason to, and it'd be annoying since they'd be different sizes, but it's not like your have infinite recursion or something preventing you from doing that. What I meant is something else though. A linked list is a linked sequence of nodes (or a chain of nodes, if you wish to call it that). A branch is a linked DAG of nodes, if you wish to call it that. Calling a branch a sequence of commits feels like calling your extended family (or I guess your genealogy) "a sequence of people" - it misses some crucial aspects of the structure and just sounds very confused.
deleted 4y ago
[deleted]
roboben 4y ago
I am not saying a branch is nothing than a ref, I am saying there are only refs in git and this is the powerful part of it because being so arcane and simple makes it so flexible
manmal 4y ago
I think the author put it well. Branches are an abstraction (albeit a leaky one) over refs, and abstractions are useful. Tags are also just refs, but we (and the git client) assign them a different semantic meaning and functionality than branches. Using those names for different ref types creates shared meaning between people around the world. They allow further abstractions like git flow, which in turn allow (in a way) CI/CD or analysis software to build on those conventions.
drewcoo 4y ago
Subversion still exists. So does Perforce. There may be others. This mental model fits those models in the code. It also fits Git-Flow. Those are all authoritarian. So is everything Linus produces. But, the secret genius of Linus is that he creates things with branchier futures than most creations and then he lets them wander around, becoming even more aggressively future-branching. No, actually . . . the secret is what allows him to do that. It is at least two derivatives of "creates branchy things . . . go!" Thus git. Thus Linux.
satisfice 4y ago
Some people are really into Git.
quadhome 4y ago
A commit is also a sequence of commits.
PeterWhittaker 4y ago
Yes and no. Especially once one considers how a remote branch is not a branch in the local sense. If that struck as odd, consider reading this, which I wrote sometime ago when a number of pennies dropped: https://peter-whittaker.com/ https://peter-whittaker.com/
- OkayPhysicist 4y ago
  More precisely, a remote branch is just like any other branch, it's just not the same branch as the local one. The origin/master vs local/master can be thought of identically to local/master vs local/my_fun_branch, plus some helper functions for remotely controlling the remote repo.
beej71 4y ago
A "branch" is two things. In git, it's the ref. To humans, it's the ref or the chain of commits under it. Both of these have their place, I feel. When thinking about commits to a branch, humans (I speculate) tend to imagine the branch as a sequence of commits. But when operating on the branch ref itself, like when you delete it, you should be very clear that you're not deleting commits.
- mirekrusin 4y ago
  Branch is ref. Chain of commits is distance between two commits/refs/their first common commit (branch point). If people working on the repo branch off main branch 99% of time, its meaning is quite straight forward. If they branch of a branch, it's also obvious what it is. As branching point is always defined so is equivalence between those two. What's the point in arguing about it? It's a bit like arguing if `Line = { a: Point, b: Point }` is a line or two points.
  - voxic11 4y ago
    There is no need for a "branch point" you can create multiple "branches" that are just references to different points on the same linear sequence of commits.
    - yamtaddle 4y ago
      You can have branches that are and have always been entirely disconnected from one another, for that matter. With completely different content, but still in the same repository.
      - jononor 4y ago
        Quite rare in practice though. Only case I have had that is gh-pages branch in a GitHub project repository, which contained only generated artifacts (generated by code in master). Which I believe there are better ways to do now. At least with Gitlab one instead uses a "pages" CI job, triggered from master, and the artifact it produces is the contents that will be hosted.
berjin 4y ago
It's a shame Mercurial became a betamax since it's much more user friendly.
- sinistersnare 4y ago
  How does Mercurial differ in this way? I always figured mercurial was just a 'better UI', but using similar internals.
- BeFlatXIII 4y ago
  Much like Betamax, the technically superior option often fails in the market.
aequitas 4y ago
When teaching Git I often use a whiteboard with a permanent marker and Post-its for branches. It really brings home the point of the commits themselves being rigid and branches flexible.
- 0cf8612b2e1e 4y ago
  That’s a great visual. I am on deck to give a mini git tutorial, and I am stealing this.
mschaef 4y ago
I tend to think of branches in git the same way I think about strings in C or lists in (Common) Lisp. In each of these cases, there's a simpler underlying data structure that's directly overlaid with a set of conventions. It's the conventions on the use of the simpler structure that gives the illusion of some higher order data type. (The distinction I'm making between these and abstraction in general is that here the abstraction is almost intentionally somewhat leaky - presenting both strengths and weaknesses.)
totorovirus 4y ago
I thought git branch is an alias to specific commit...
expazl 4y ago
It reads a bit like the author has a misconception of what commmits are. A commit is not a diff, it's a snapshot. All of the talk about branches containing changes etc, make sense in the context of it being a reference to the latest snapshot. And yes it might not make sense if you think of a branch as a reference to the latest difference, but this is a misconception.
- tantalor 4y ago
  Came here to say this. Commits on a branch should be as easy as "save file". You shouldn't put commit messages on them other than something like "snapshot 3". Nobody cares about the commits on the branch.
  - justinclift 4y ago
    That sounds weird to me, as commit messages in a (side?) branch are just as useful as commits on the main development branch. eg very, as they describe what that change did Maybe the only time / scenario I'd agree with you though, is when I'm just creating a commit to capture a temporary development state (eg WIP) on the way to some development objective. That's not very often though.
  - slaymaker1907 4y ago
    For certain changes, a clean branch history can be very valuable during review. For example, if you had some feature which was rolled back due to bugs, a new branch with the feature plus the fixes should have the original (buggy) feature as the first commit(s) with no other modifications so that people can clearly see what was done to fix the original bugs and what was in the original code. However, you can fix things up when ready for review by just rebasing things into a coherent sequence of commits. I really wish there was a good autocommit/push feature in Git that would help back things up but continuously rebase and compact old autocommits.
    - titzer 4y ago
      It's true. Making a very clean git commit history is key to making the most use of git. That's partly in choosing sizes of commits (does one thing, not two things), partly in choosing good commit messages, and partly in branching strategy. Personally I try to avoid merges at all costs. Instead, I always try to keep feature branches cleanly rebased off master. This sucks with github, so I have a tendency to destroy and recreate feature branches to avoid getting merge commits mixed up in the remote. GitHub is dumb like that. I don't really know how to fix that except to suggest that some branches on remote should be auto-rebased if it can be done cleanly. But it's still a pain.
chclt 4y ago
I think this highlights a deeper issue with how we as programmers tend to think about abstractions. It is easy to pretend, that you can conjure any interface/any abstraction from thin air as long as you define what you want well enough. But the reality is, that a good abstraction needs to be build using elegant constituent parts. It needs to be built in a way, which looks at the problem in an angle which simplifies it. Building named sequences of source changes via commits which chain together, with the only thing that defines the identity of the chain being a ref to the end is such an elegant abstraction, which is not bad to expose; It allows for easy reasoning about source changes. Saying git branches are a seperate sequence of commits and keeping it at that would be not a good abstraction, even if you hid the implementation really well.
comfypotato 4y ago
This article begs for git manual awareness. I’m fairly certain the author doesn’t know the manual exists. It’s a short manual. The chapters through branching should be required 1.5 hour reading. It’s stupidly simple when it’s broken down correctly. (The plumbing chapters are admittedly over my head.)
OJFord 4y ago
I think you can be technically accurate ('branch is a named ref') and still have the same mental model of branches described. A commit, specifically its ref, is already encoding the 'sequence of commits' that led to it - viz. it knows its parent(s). A branch is a named pointer to one of those then, and 'nothing more', but that is already a sequence a commits.
- Oxidation 4y ago
  > and 'nothing more' Also it "follows along" when you commit to the branch. Named pointers that stay put are tags.
  - OJFord 4y ago
    Good point, that is a bit of a quirk to the model. (Bloody useful, wouldn't have it another way obviously. But it is a special treatment more than 'a name for a commit'.) I suppose I can recover by saying 'committing creates a new commit, with HEAD as parent, and updates the checked out pointer to point at it'. Where no branch, a 'detached HEAD', is perhaps more thr special case - it's a sort of nameless transparent pointer that updates but you're only aware of the commit ref itself. Although again tag is also a special case in that it doesn't update, as you say. Really they're just all different ways of referring to a commit, doesn't really make sense to call any one of them the true way and the others special cases. I stand by the commit being the 'sequence of commits' though. So tldr, branches, tags, detached heads are just different mechanisms for referring to such a sequence: named and updates, named and static, unnamed/transparent. But in each case, they point to a commit, and inherently the sequence behind it.
- bigiain 4y ago
  It seems to me that "a branch is just a ref" is important knowledge to anyone developing git software or any other software that interacts directly with the files in a git repo. For pretty much every other developer who's just using git for source control, "a branch is a named sequence of commits" is a much more useful way to understand them. I don't want to think about the implementation details of how git internally represents a branch any more than I want to think about whatever's going on inside a word .doc when I add a table into my document. The important thing is my branch (or table) works the way I and everybody else expects it to work. (It's good to have at least one person on your team who understands both those concepts deeply, as the obligatory xkcd explained...)
xn 4y ago
Describing a git branch as a named sequence of commits implies that it's a specific sequence of commits. But without a merge base, a branch is an ambiguous sequence of commits. Ergo, a git branch is a named sequence of commits [when the implied merge base is obvious].
- smusamashah 4y ago
  I dont understand what author is trying to say. I always understood branch as just a pointer on a linked list of commits. You can freely move around this pointer. Head is similarly another pointer to the current commit. This plus each commit is contains whole file which was changed in that commit. Is author saying the same thing or is he saying that each commit also has some hard-coded reference to the branch in it too?
- Karellen 4y ago
  I'm struggling to follow why a merge base makes a difference? Or even exactly what one is? A couple of questions which might help clear things up: Do you consider `main` a branch? If you create a new branch called `feature1`, do you consider the commits from before the branch from `main` to be "part of" that branch or not? What if you delete `main`? Are the commits from before the branch part of the `feature1` branch then? What if there are multiple surviving feature branches that share varying amounts of common history?
  - xn 4y ago
    main is a branch. By convention, it contains all of the commits back to an ancestor that has no parents. Unless given more information, I would consider the commits between `git merge-base main feature1` (exclusive) and feature1 (inclusive) as part of the feature1 branch. Now, if I `git checkout -b feature1-A feature1`, what commits are part of branch feature1-A? It depends. With respect to which merge base?
smusamashah 4y ago
Aren't git branches just linked lists in reverse? Since it's a reverse linked, you add to HEAD pointer instead of tail. And because it's reverse, you can branch out with any number of pointers (aka branches).
somewhereoutth 4y ago
I think of a git repo as a gigantic bramble bush, with some of the brambles joining back into each other. There are some labels attached to the bramble bush in various places. Some of the labels follow the tips as they grow, some stay fixed. It gets interesting when you compare two bramble bushes with the same provenance, see how they differ, and then how they can be reconciled.
throwbadubadu 4y ago
I want to argue... tags are that. Branches are usually ever changing and sometimes disappearing sequences of commits. ymmv (: (And now don't tell me that also tags could change, and branches not.. then we are almost back to it is all refs - btw why so mad about that? It is another valid viewpoint imo).
falseassertions 4y ago
I am sad that this article exists, let alone all this discussion. It feels like that sort of take that is put out there just to be contrarian and stir the pot. I don't think I've ever seen someone say "a branch is a ref" with the intent to diminish the concept of a branch or the utility of it, or the special language around it's concept. On the other hand, appreciating what git commits are, what tags are, what branches are, and understanding the "just refs" part of it, was vital to my understanding of git. This article feels like it argues against something that (1) doesn't exist, and (2) in the form in which it does exist, serves a vital role of exposing 'just enough' of git to help some folks understand the model enough to be effective with it.
GuB-42 4y ago
I am glad no one told me that because I would have caused me a lot of confusion. Git branches, the thing the "git branch" give you are pointers to a commit, or refs if you wish. It has several implications: you can move them at will, and after a merge, you lose track of what "sequence of commits" it originally was. I came to git from mercurial, and while they are fundamentally very similar, branches are a major difference because in mercurial, branches are really a named sequence of commits. Each commit of the branch is tagged with the branch name, and it will stay that way, even after a merge. You can't change or delete branches, only append to them or close them. Git-style branches also exist in mercurial and they are called bookmarks, so maybe you can call them that. Now there is the higher concept of branching that includes cloning and is not specific to git, and we can indeed call a branch a sequence of commits, but "git branches" have a precise meaning, and it is not that. Anyways, git is terrible at naming things, especially when it comes to its command line, one of the biggest flaws of an otherwise great version control system.
- alexvoda 4y ago
  Maybe the conclusion then is that when "higher concept of branching" means something, and other tools like mercurial align with that meaning, it is git that is wrong by using a different meaning. Git could have called their branches bookmarks too. If Bob insists on calling vodka "Bob water", and someone asks for some water to put out a fire and Bob gives them vodka, there is a problem even if "Bob water" has a precise meaning.
pcj-github 4y ago
A git branch is a text file containing a single sha1 value and a newline. Pretty sure the author can't tell me the named sequence of commits given that information.
- sgustard 4y ago
  A complex data structure is just a pointer. A file is just a pointer. My whole identity and personhood is just a pointer.
TeeMassive 4y ago
..that grows from the leaf
pictur 4y ago
someone who wants to experience hell can try to work in the same job with someone who has the same style as this blogger.
klysm 4y ago
My mental model is that a branch is a pointer to a commit, along with the other semantics of the git tooling that deal with branches. Specifically merge bases.
avgcorrection 4y ago
Don’t understand why this blog is featured so often on this site.

170 points by EamonnMR 4y ago

A ref is a pointer to a node in an directed acyclic graph, and a branch is a pointer to a ref. Not all subgraphs of directed acyclic graphs are sequences. So, not all branches are sequences.

p-e-w 4y ago

I wish we had a version control system that can be used without worrying, or even knowing, about its technicalities and implementation details. Working with Git for version control is as if your photo management tool required you to learn about inodes and b-tree superblocks in order to save a JPEG file. I just want to keep source code history, and allow multiple people to collaborate on the same project. I don't want to know anything about "refs" or whatever else is happening behind the scenes, yet it appears Git can't be used unless you are (at least occasionally) willing to look at the plumbing layer.

cratermoon 4y ago
If there's a UI, or even a CLI, that properly matches the conceptual model of development with git, I'm not aware of it. I'm sure there's a much clearer user-centric model of work struggling to get out from underneath the implementation details. Over the years of working with git I've gradually learned bits of the plumbing underneath the porcelain, but reluctantly.
graypegg 4y ago
Version control feels like it does require some complexity though. I think we all like to imagine that all it does is stores changes per file, wrapped in commits. But when you add requirements like merging other people’s work with yours, movable “tags” to mark named versions, and the sort of cut/splice/move around operations you will always need because you accidentally did something you shouldn’t have… I think you end up rebuilding most of Git’s plumbing.
- p-e-w 4y ago
  Video codecs are also complex (actually, they are almost unimaginably complex). But I've never seen a smart TV telling the user something about "lapped transforms" or "chroma subsampling". I'm a user of Git. Why do I have to learn about implementation complexities in order to fix problems that arise from normal version control operations? I can't think of any other software that forces me to do this. Even compilers (at least those for mainstream programming languages) don't require me to understand their AST representation or other details of how they work internally.
  - taeric 4y ago
    Televisions absolutely do this for power users. Or give them terrible image quality for regular users.
  - graypegg 4y ago
    WildBit had a really cool project a while ago called Conveyor. [0] It’s a shame it never took off. It was built on git, but hid the complexity of branching + other git things behind “tasks”. You’d start a task, and silently push that branch out to everyone. It’d silently merge things in the background and handle a lot of the chores you have to do with git rebasing and such to keep branches mergeable. It failed miserably with us because it perpetually created impossible to solve git issues. Someone accidentally removes a gitignore file and commits a config file with a password? Your SOL. It will keep coming back because it will exist on at least one other person’s device which will get force pushed back to the repo. The weird plumbing exists because version control is hard, and prone to humans throwing wrenches into its nominally perfect system. The real reason you don’t remember every magic git incantation is because you normally only need a specific one, once a year. But it has to be there! [0] https://web.archive.org/web/20190226201600/https://conveyor.com/ https://web.archive.org/web/20190226201600/https://conveyor....
  - theamk 4y ago
    TVs are consuming devices. If you are only wishing to consume git, you need to know "git clone" and "git checkout", and that's it, no need for internals. Or manybe not even that, you need to know where "download" link on Github interface is. If you are encoding video, you often need to know about chroma subsampling, and colorspaces, and fractional framerate and all the other absurd technical details. It is actually much worse than git. You can avoid those technical details if you use high-level software, only stay on happy path, and avoid any complex operations. You'll take longer and produce worse quality output than if you had fully mastered the software -- but often this is OK. This is true both for video encoding and for git.
rjbwork 4y ago
We do, at least to my mind. It's called Mercurial. It's great, extremely close to git, but is much easier to use IMO. It's really a damn shame that git won - primarily, I think, due to the cachet of its author.
- dilyevsky 4y ago
  The way I remember it git one for two reasons: 1. hg was (maybe still is?) much slower 2. “No technology can ever be too arcane or complicated for the black t-shirt crowd” (fake Linus’s words not mine)
  - gregjor 4y ago
    I think you’re quoting me. Thanks! https://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and-git https://typicalprogrammer.com/linus-torvalds-goes-off-on-lin...
- bigDinosaur 4y ago
  Either way, is Git actually that hard to use? You can learn about 10 commands and develop any software just with those. I have no illusions about it's gnarly aspects but also just don't find it particularly difficult. Contrast a programming language that might have footguns in just printing strings.
  - photonbeam 4y ago
    Git is a pain to provide support for if you’re an internal tools team, lots of users with incorrect mental models
- shanev 4y ago
  Close. It won because of Github. Git was gaining over SVN slowly but it was Github that really propelled it into widespread use.
Agentlien 4y ago
Why do you feel you need to know these details? I used git actively without issues for years before I took the time to learn how it works under the hood. While understanding the details was fun and helpful, I can't say it really changed much about how I use the tool.
bad_username 4y ago
Linus built an incredibly elegant and simple underlying model for git. For what it successfully does - distributed version control - it is remarkably simple and easy to grasp if you want to. However, this model was not mapped well to the high level concepts that the typical user of a VCS operates in. This is the biggest issue of git: it's hard to make sense of it by its UI if you do not understand how it works under the hood. I struggled until I read the pro git book. I wouldn't go as far as to compare this to knowing about filesystem data structures for saving a jpeg file. It's more like using an old school file dialog where you just see the bare file system and you need to know your way around your drive.
- josephg 4y ago
  Git's other (compounding) problem is how the CLI is an inconsistent mess. Why do you create a branch via the "git checkout" command? Why do you delete tags using "git tag -d" but delete stashes using "git stash drop"? If you want to blow away local uncommitted changes, you can use "git reset", "git reset --hard" or "git checkout (file)" - which (I think) all do totally different things. Git's data model may be elegant, but its hard to appreciate it through the tangled mess of git command line options.
  - Nadya 4y ago
    I use Git daily and literally couldn't tell you how to use it because I've aliased every single command it has. I basically have a wrapper over it and to teach anyone how to use Git I have to peel my layer away and check what I have things aliased to. It feels like terrible ad hoc user design built over an otherwise extremely elegant and clean data model.
    - freetonik 4y ago
      Would you mind sharing your aliases? Curious to see a different mental model.
  - amadvance 4y ago
    They tried to fix that mess, like with the recent git switch/restore. But it looks like it was too late.
taeric 4y ago
You've clearly never tried to save raw image files from a mid level camera. :) heaven help you if you try a newer camera than your os. I will make no major defense of git, but I am intrigued at the level of difficulty reported about it, compared to the obviously higher level of use that it gets.
- ansgri 4y ago
  What kind of cameras and difficulties are you talking about? It’s almost always just a DCIM folder on the sd card. Videos, OTOH, are stored rather arcanely, at least on my Sony, with separate directory structure for each format.
  - taeric 4y ago
    Newer cameras have had raw formats that were not supported right away. Cr3 being the one that bit me recently. I think most software has caught up. But it did catch me off guard that my machine needed updating to support this. I also think flatpak had some trouble with it. Can't remember details.
    - ansgri 4y ago
      Ah, you're talking about actually using them, not just saving :)
      - taeric 4y ago
        Little of both. Took me a few tries to get them recognized as pictures. Rather frustrating experience, all told.
seba_dos1 4y ago
"refs" are not behind-the-scenes things, they're the things you want to operate on. It wouldn't be like having to learn JPEG superblocks, it's more like learning what a pixel is. You need to understand Git's data model, not its plumbing. No VCS will be useful for anything that isn't trivial if you don't understand its data model.
- Gunax 4y ago
  I disagree. We shouldn't have to know how a branch or commit is stored. Whether git interally makes a new ref, copies everything to a new directory, or does some hashing magic doesn't matter to the user. I agree that we end up needing to know about refs because of git's user interface, but I consider that a flaw or limitation.
  - seba_dos1 4y ago
    It's not about "how a branch is stored". We're not talking about objects, packs, blobs or any other stuff I never actually had to learn about while using git. We're talking about refs - the primary way for users to reference commits and other things in git. Just about every command you use takes refs as arguments. It's essential to even just imagine the state of the repository in your head. It's what the first tutorial you read about git should explain to you.
aaronbrethorst 4y ago
There's something funny to me about the idea that the user-level Git commands are called the "porcelain," as if they were a toilet. https://stackoverflow.com/a/6976506 https://stackoverflow.com/a/6976506 unrelated: I wish people would stop insisting on using full-width columns to display their blog content because it is nearly impossible to read on a 27" monitor. Wrap that blog content with a <div style='max-width: 65ch'>
- thiht 4y ago
  > I wish people would stop insisting on using full-width columns to display their blog content because it is nearly impossible to read on a 27" monitor. There's a noticeable portion of tech people who seem to believe that unused screen space is somehow wasted. No margins + no line breaks is the gold standard to them. I don't get it, it's unreadable to me.
  - phist_mcgee 4y ago
    Dan Luu is famous for this. I can barely read the page it's so harsh. eg. https://danluu.com/futurist-predictions/ https://danluu.com/futurist-predictions/
- drdec 4y ago
  You don't have to run your browser maximized you know
  - aaronbrethorst 4y ago
    Please tell me about how you will replace me with a very small shell script next.
  - phist_mcgee 4y ago
    Telling someone to change their workflow because a website refuses to deal with larger screen sizes is silly.
    - 4y ago
thunderbong 4y ago
That's why we use fossil [0]. It just gets out of the way. It has its own server, wiki, ticket system and now, even chat! The main complaint I see here is that it doesn't have rebase, and my point is the goal of the code is for the product to work, not to have a beautiful commit graph. I've used CVS, SVN, Git. But nothing comes close to the usability that fossil provides. [0]: https://www.fossil-scm.org/ https://www.fossil-scm.org/
- vbezhenar 4y ago
  Beatiful commit graph allows to actually understand commit history. I dread opening history with merges. It's always incomprehensible mess for me.
somat 4y ago
I use the heck out of fossil and have little idea how it works underneath. I consider fossil the gold standard for a good versioning system ui. I don't think git has any excuse for being as weird as it is. fossil init repo; make a new fossil repository fossil open repo; open a fossil repository somewhere fossil add file; note: very different than git add. in fact I was very confused by git add, in fossil the repository knows what files are managed by it and there is no staging area. so you only use "fossil add" when adding a new file. If you move a file use "fossil mv" to let fossil know what you did. Along with "rm" when you remove a file. The staging area still feels like an unnecessary added bit of friction. fossil commit There are others I use often "merge", "sync", "revert" but they tend do what the command appears to do. Speaking of revert, the git equivalent is really strange , even among the rest of the strange git ui. Shit! I messed something up and want to revert back to the last committed change, easy, just run the command "git reset --hard HEAD"
- KRAKRISMOTT 4y ago
  The bad thing is that fossil allows the upstream to make destructive changes to client's copy of code. That's a big no no.
  - owyn 4y ago
    Until you need it. :)
  - somat 4y ago
    So does git, in fact, without a better explanation of what exactly you mean, I would say upstream making changes to the the clients code is the core useful property of a version control system.
- osigurdson 4y ago
  git init . git add file git commit -am "my message" Pretty simple really. You don't need to think about staging if you don't want to.
  - dataflow 4y ago
kaba0 4y ago
People mention previous gen version control systems in sibling comments, but git quite clearly “won” against them. A more useful outlook would be looking for what the next gen VSC might be, which would be Pijul and alia (where diffs/patches are applicable in any order, so merges will be trivial, no more merge strategies), and if they do get production ready they might really provide a better UX/more intuitive mental model for the programmer.
ozim 4y ago
My view on it is that unfortunately there is no way to do that. Some things are going to be hard and that is it, you cannot make it easier. We see that in never ending stream of frameworks or "new/better/easier" ways which in the end become bloated in the same ways as most other stuff because problems don't go away if you don't know about them. In the end data model of git is its killer feature because it gives me tools to deal with hard problems and do it efficiently.
- comfypotato 4y ago
  I always feel that complaints like the one you’re replying to aren’t thought through. The simple follow up is: how would you do it better? There’s no better way. You only need to look at the complicated part of git for very complicated things. If you think about it, commits and branches are incredibly simple relative to what’s actually happening (when it comes to working with them, that is). Listening to old folks talk about pre-git version control gives me appreciation for just how good it is.
  - OkayPhysicist 4y ago
    There are a few fixes I would make, but only a handful would be significant to everyday usage, none would involve fundamentally changing the underlying data model. The biggest would probably be to make all commits required to be made onto branches and either embed the data of what branch created a commit into the commit itself, or have a separate data store of branch-to-commit info, which would allow for "branches as a series of commits" to be a first class citizen besides "branches as references to a commit". Maybe add git notes-esque support for editable metadata on the branch, where you could put information that currently would be stored in some pull request management system.
    - comfypotato 4y ago
      The data regarding what branch a commit was made is available. It’s all available if you dig deep enough. What you’re talking about sounds like the work of a git visualization tool made for fixing problems. I do love a repo viz where I can see the tree of branches for helping me understand where something went wrong. The surface level stuff people use day to day is as simple as it needs to be.
xorcist 4y ago
All abstractions leak. You cannot work your jpeg photo collection but opening, editing, saving, editing, saving, editing, saving and then blame your tools when your jpegs are blocky and ugly. First you have to know some basics about lossy compressing and destructive editing. Then, you can understand what steps you really want to take. It's the same with version control systems. With git, first you have to understand what a commit and a branch is. Then, you can work.
OkayPhysicist 4y ago
It's version control for software developers, who simultaneously need all the power it provides, and ought to have the educational background to understand directed acyclic graphs. Complaining that git is too complicated because it requires basic knowledge of DAGs is like complaining that your word processor is too complicated because it assumes a proficiency in written language.

draw_down 4y ago

It’s not helpful to say branches are only refs as a way of arguing branches don’t exist. But it is helpful in understanding how they work, what it means to pass a branch argument to git for some operation. When I understood the reflog and how nothing I do is really gone (just gotta find it!), that was when I realized how much I like git.

littlestymaar 4y ago
> When I understood the reflog and how nothing I do is really gone (just gotta find it!), that was when I realized how much I like git. The reflog won't help you recover things in the staging area that where accidentally `reset --hard` though … (you can still get the ones you added to the index with `git add` but not committed[1], but changes that weren't added are lost for good) I love git, but the UX is still terrible … [1]: https://stackoverflow.com/questions/7374069/undo-git-reset-hard-with-uncommitted-files-in-the-staging-area https://stackoverflow.com/questions/7374069/undo-git-reset-h...
- draw_down 4y ago
  [dead]
- buck4roo 4y ago
  Why do you love it? It looks like you've described a tool with 1) a terrible UI, and 2) trains users to use commands that will eventually cause them to lose unsaved work.
  - littlestymaar 4y ago
    1. git has a terrible UX (not UI), including destructive actions without warning and much more really cumbersome things for newbies to learn about 2. once you know it enough, git is a powerful tool that I really appreciate. 1. and 2. aren't contradictory. And I would love git even more if the UX wasn't the dumpster fire it is, but I happen to know enough of its bad UX to be able to do what I want with it. Also, unlike the average git expert on HN, I still recognize that the UX is shit, and that you should need to spent as much time as I did in order to be able to use it at all. I'm really annoyed when people argue that a bad UX is in fact good because of some elitist reasoning.

cybrexalpha 4y ago

> It's true that Git implements branches as refs, plus also a nebulous implicit part that varies from command to command. But that's an unfortunate implementation detail, not something we should be committed to. I actually find git way easier to understand if I don't think about branches in the way the author suggests. My mental model for git really is commits and refs, and it helps me use it fluently. When I wave my hands around and say "a branch is nothing but a ref" what I actually mean is "...and so you should understand how it actually works, so what I'm about to do doesn't look like magic".

Gunax 4y ago
I think you and the author are right, but addressing different audiences. I think most people come to git with their own mental model of what a branch is, what a merge is, etc. Learning git is often mostly undoing their preconceptions (ie by saying 'a branch is just a ref'). But ultimately, we humans tend to think of a branch as a branch, not a ref. For instance, the previous sentence probably made perfect sense to you.
- topaz0 4y ago
  I agree, and would add that this is exactly what the OP is saying when it talks about this being a communication issue. Saying "a branch is just a ref" is the right attitude for talking to git and making it do what you want it to do, but it's the wrong attitude when you are writing or talking about code, in which case branches are the reification of the processes by which your code evolves.
- edflsafoiewq 4y ago
  Do they? I certainly had no intuitive notion of how version control would work before I learned git for the first time.
  - Name_Chawps 4y ago
    You did have an intuitive notion of what the word "branch" means, though.

brianpan 4y ago

I'd argue that there's a difference between a git branch (an implementation detail) and a development branch (a process feature) and that's the difference the author is running up against. Are you teaching someone about development? Or teaching about git? Because a git branch IS a ref. And a git branch is useful because it points at a commit in a series of commits. Branches and commits are slightly different concepts depending on your VCS and it can be worth understanding the details.

_ZeD_ 4y ago

[insert obligatory mercurial comment here]

xvilka 4y ago

This is why there is a hope to build a new VCS that isn't that state-dependent and based on isolated patches - Pijul[1]. [1] https://pijul.org https://pijul.org

seba_dos1 4y ago

> None of these can be understood if you think that a branch is nothing but a ref. To the contrary - all of these can have "branch" changed to "ref" and they still make perfect sense. "ref" is just as much a sequence of commits as "branch" is. Every commit is.

paweladamczuk 4y ago

I'm pretty sure every person who says "branches are nothing but refs" understands why they are called branches. They just want you (and others) to learn. This is an important piece of puzzle that many people miss. Would you sacrifice all those (other people's) learning opportunities just so that you don't get annoyed?

deleted 4y ago
[deleted]

vhab 4y ago

The comments in this thread are very interestingly making the Author's point. Yes, you can be "technically correct" saying branches are just refs, but it's not a useful statement for most users. I believe the author makes a very valid point, and we could do with a bit less "technically correct" and more with language targeting the usage rather than technical implementation. Git is confusing enough for many people, and we don't have to make it more confusing for them.

metafunctor 4y ago
I'd argue git is confusing for many people because they don't understand the data model. The solution is to learn the basic data model instead of pretending that "a branch is a ref" is not true. Because it is true.
- coldpie 4y ago
  For anyone reading this who would like to learn about the data model, I highly recommend following along the "gitcore-tutorial" manpage. Like actually type the commands and play around with the results. Once you understand what's going on under the hood, the UI commands all make intuitive sense.
- jameshart 4y ago
  A branch is not a ref. A head ref is a ref that names a branch. But branches can exist in git without refs. Branches are artifacts that exist in the commit DAG - they are dangling chains of commits that end without being merged in to some other commit. They exist, as pure platonic branches, even if they are un-referenced. But then you can make a head ref and name one and now all of a sudden you have a named branch. As you make more commits that extend the branch while ‘attached’ to that head, the head ref follows the tip of the branch (that is in particular a thing a head ref does that a tag ref does not). But you can add commits and extend a branch in a detached state of you like - no head refs following the branch tip. Yet the branch definitely exists. And then if you tag it, you name it. So no, I don’t think “a branch is a ref” tells the whole story.
  - 4y ago

abstrakraft 4y ago

OP argues that branches aren’t “just refs”, they’re a sequence of commits. I’d argue that a ref _is_ a sequence of commits. (Or, to be pedantic, it uniquely identifies a sequence of commits.)

deleted 4y ago
[deleted]
_cenw 4y ago
A commit contains a sequence of commits, in fact (unless it is the root commit). So a ref is just a single commit, which then contains parent commits. The branch model really falls apart if you ever do a more complex merge or rebase.

davidw 4y ago

git branches are just a monoid in the category of endofunctors. Did I get that right?

dataflow 4y ago

I feel like I have a bigger problem with "a sequence of commits" as a phrase than I do with whatever he wishes to call a branch. A commit itself is a sequence (it includes its own history!), so a sequence of a sequence is a confusing thing to talk about without any sort of qualification, since they're heavily constrained by being linked together. Moreover, what he's calling a sequence is really a DAG; it's not linear. Hearing "a sequence of commits" is so jarring that it conveys more confusion about git than anything else... perhaps that's why he gets corrected so often? But in terms of what a branch is, if you don't want to call it a "ref", then I'd just say it's a commit symlink?

LegionMammal978 4y ago
Hmm, I think you'd be going a bit far by calling each commit a sequence. A commit does not contain its parent commits: it only contains pointers to its parent commits. By that logic, a linked list isn't a sequence of nodes, since each node is itself the head of a sublist.
- dataflow 4y ago
  The pointer isn't really relevant to what I'm sharing. I'm talking about what it is logically, not how it might be represented physically. You could certainly make each commit contain the other one physically if you wanted to represent it that way in some programming language. Of course there's not much of a reason to, and it'd be annoying since they'd be different sizes, but it's not like your have infinite recursion or something preventing you from doing that. What I meant is something else though. A linked list is a linked sequence of nodes (or a chain of nodes, if you wish to call it that). A branch is a linked DAG of nodes, if you wish to call it that. Calling a branch a sequence of commits feels like calling your extended family (or I guess your genealogy) "a sequence of people" - it misses some crucial aspects of the structure and just sounds very confused.

deleted 4y ago

[deleted]

roboben 4y ago

I am not saying a branch is nothing than a ref, I am saying there are only refs in git and this is the powerful part of it because being so arcane and simple makes it so flexible

manmal 4y ago

I think the author put it well. Branches are an abstraction (albeit a leaky one) over refs, and abstractions are useful. Tags are also just refs, but we (and the git client) assign them a different semantic meaning and functionality than branches. Using those names for different ref types creates shared meaning between people around the world. They allow further abstractions like git flow, which in turn allow (in a way) CI/CD or analysis software to build on those conventions.

drewcoo 4y ago

Subversion still exists. So does Perforce. There may be others. This mental model fits those models in the code. It also fits Git-Flow. Those are all authoritarian. So is everything Linus produces. But, the secret genius of Linus is that he creates things with branchier futures than most creations and then he lets them wander around, becoming even more aggressively future-branching. No, actually . . . the secret is what allows him to do that. It is at least two derivatives of "creates branchy things . . . go!" Thus git. Thus Linux.

satisfice 4y ago

Some people are really into Git.

quadhome 4y ago

A commit is also a sequence of commits.

PeterWhittaker 4y ago

Yes and no. Especially once one considers how a remote branch is not a branch in the local sense. If that struck as odd, consider reading this, which I wrote sometime ago when a number of pennies dropped: https://peter-whittaker.com/ https://peter-whittaker.com/

OkayPhysicist 4y ago
More precisely, a remote branch is just like any other branch, it's just not the same branch as the local one. The origin/master vs local/master can be thought of identically to local/master vs local/my_fun_branch, plus some helper functions for remotely controlling the remote repo.

beej71 4y ago

A "branch" is two things. In git, it's the ref. To humans, it's the ref or the chain of commits under it. Both of these have their place, I feel. When thinking about commits to a branch, humans (I speculate) tend to imagine the branch as a sequence of commits. But when operating on the branch ref itself, like when you delete it, you should be very clear that you're not deleting commits.

mirekrusin 4y ago
Branch is ref. Chain of commits is distance between two commits/refs/their first common commit (branch point). If people working on the repo branch off main branch 99% of time, its meaning is quite straight forward. If they branch of a branch, it's also obvious what it is. As branching point is always defined so is equivalence between those two. What's the point in arguing about it? It's a bit like arguing if `Line = { a: Point, b: Point }` is a line or two points.
- voxic11 4y ago
  There is no need for a "branch point" you can create multiple "branches" that are just references to different points on the same linear sequence of commits.
  - yamtaddle 4y ago
    You can have branches that are and have always been entirely disconnected from one another, for that matter. With completely different content, but still in the same repository.
    - jononor 4y ago
      Quite rare in practice though. Only case I have had that is gh-pages branch in a GitHub project repository, which contained only generated artifacts (generated by code in master). Which I believe there are better ways to do now. At least with Gitlab one instead uses a "pages" CI job, triggered from master, and the artifact it produces is the contents that will be hosted.

berjin 4y ago

It's a shame Mercurial became a betamax since it's much more user friendly.

sinistersnare 4y ago
How does Mercurial differ in this way? I always figured mercurial was just a 'better UI', but using similar internals.
BeFlatXIII 4y ago
Much like Betamax, the technically superior option often fails in the market.

aequitas 4y ago

When teaching Git I often use a whiteboard with a permanent marker and Post-its for branches. It really brings home the point of the commits themselves being rigid and branches flexible.

0cf8612b2e1e 4y ago
That’s a great visual. I am on deck to give a mini git tutorial, and I am stealing this.

mschaef 4y ago

I tend to think of branches in git the same way I think about strings in C or lists in (Common) Lisp. In each of these cases, there's a simpler underlying data structure that's directly overlaid with a set of conventions. It's the conventions on the use of the simpler structure that gives the illusion of some higher order data type. (The distinction I'm making between these and abstraction in general is that here the abstraction is almost intentionally somewhat leaky - presenting both strengths and weaknesses.)

totorovirus 4y ago

I thought git branch is an alias to specific commit...

expazl 4y ago

It reads a bit like the author has a misconception of what commmits are. A commit is not a diff, it's a snapshot. All of the talk about branches containing changes etc, make sense in the context of it being a reference to the latest snapshot. And yes it might not make sense if you think of a branch as a reference to the latest difference, but this is a misconception.

tantalor 4y ago
Came here to say this. Commits on a branch should be as easy as "save file". You shouldn't put commit messages on them other than something like "snapshot 3". Nobody cares about the commits on the branch.
- justinclift 4y ago
  That sounds weird to me, as commit messages in a (side?) branch are just as useful as commits on the main development branch. eg very, as they describe what that change did Maybe the only time / scenario I'd agree with you though, is when I'm just creating a commit to capture a temporary development state (eg WIP) on the way to some development objective. That's not very often though.
- slaymaker1907 4y ago
  For certain changes, a clean branch history can be very valuable during review. For example, if you had some feature which was rolled back due to bugs, a new branch with the feature plus the fixes should have the original (buggy) feature as the first commit(s) with no other modifications so that people can clearly see what was done to fix the original bugs and what was in the original code. However, you can fix things up when ready for review by just rebasing things into a coherent sequence of commits. I really wish there was a good autocommit/push feature in Git that would help back things up but continuously rebase and compact old autocommits.
  - titzer 4y ago
    It's true. Making a very clean git commit history is key to making the most use of git. That's partly in choosing sizes of commits (does one thing, not two things), partly in choosing good commit messages, and partly in branching strategy. Personally I try to avoid merges at all costs. Instead, I always try to keep feature branches cleanly rebased off master. This sucks with github, so I have a tendency to destroy and recreate feature branches to avoid getting merge commits mixed up in the remote. GitHub is dumb like that. I don't really know how to fix that except to suggest that some branches on remote should be auto-rebased if it can be done cleanly. But it's still a pain.

chclt 4y ago

I think this highlights a deeper issue with how we as programmers tend to think about abstractions. It is easy to pretend, that you can conjure any interface/any abstraction from thin air as long as you define what you want well enough. But the reality is, that a good abstraction needs to be build using elegant constituent parts. It needs to be built in a way, which looks at the problem in an angle which simplifies it. Building named sequences of source changes via commits which chain together, with the only thing that defines the identity of the chain being a ref to the end is such an elegant abstraction, which is not bad to expose; It allows for easy reasoning about source changes. Saying git branches are a seperate sequence of commits and keeping it at that would be not a good abstraction, even if you hid the implementation really well.

comfypotato 4y ago

This article begs for git manual awareness. I’m fairly certain the author doesn’t know the manual exists. It’s a short manual. The chapters through branching should be required 1.5 hour reading. It’s stupidly simple when it’s broken down correctly. (The plumbing chapters are admittedly over my head.)

OJFord 4y ago

I think you can be technically accurate ('branch is a named ref') and still have the same mental model of branches described. A commit, specifically its ref, is already encoding the 'sequence of commits' that led to it - viz. it knows its parent(s). A branch is a named pointer to one of those then, and 'nothing more', but that is already a sequence a commits.

Oxidation 4y ago
> and 'nothing more' Also it "follows along" when you commit to the branch. Named pointers that stay put are tags.
- OJFord 4y ago
  Good point, that is a bit of a quirk to the model. (Bloody useful, wouldn't have it another way obviously. But it is a special treatment more than 'a name for a commit'.) I suppose I can recover by saying 'committing creates a new commit, with HEAD as parent, and updates the checked out pointer to point at it'. Where no branch, a 'detached HEAD', is perhaps more thr special case - it's a sort of nameless transparent pointer that updates but you're only aware of the commit ref itself. Although again tag is also a special case in that it doesn't update, as you say. Really they're just all different ways of referring to a commit, doesn't really make sense to call any one of them the true way and the others special cases. I stand by the commit being the 'sequence of commits' though. So tldr, branches, tags, detached heads are just different mechanisms for referring to such a sequence: named and updates, named and static, unnamed/transparent. But in each case, they point to a commit, and inherently the sequence behind it.
bigiain 4y ago
It seems to me that "a branch is just a ref" is important knowledge to anyone developing git software or any other software that interacts directly with the files in a git repo. For pretty much every other developer who's just using git for source control, "a branch is a named sequence of commits" is a much more useful way to understand them. I don't want to think about the implementation details of how git internally represents a branch any more than I want to think about whatever's going on inside a word .doc when I add a table into my document. The important thing is my branch (or table) works the way I and everybody else expects it to work. (It's good to have at least one person on your team who understands both those concepts deeply, as the obligatory xkcd explained...)

xn 4y ago

Describing a git branch as a named sequence of commits implies that it's a specific sequence of commits. But without a merge base, a branch is an ambiguous sequence of commits. Ergo, a git branch is a named sequence of commits [when the implied merge base is obvious].

smusamashah 4y ago
I dont understand what author is trying to say. I always understood branch as just a pointer on a linked list of commits. You can freely move around this pointer. Head is similarly another pointer to the current commit. This plus each commit is contains whole file which was changed in that commit. Is author saying the same thing or is he saying that each commit also has some hard-coded reference to the branch in it too?
Karellen 4y ago
I'm struggling to follow why a merge base makes a difference? Or even exactly what one is? A couple of questions which might help clear things up: Do you consider `main` a branch? If you create a new branch called `feature1`, do you consider the commits from before the branch from `main` to be "part of" that branch or not? What if you delete `main`? Are the commits from before the branch part of the `feature1` branch then? What if there are multiple surviving feature branches that share varying amounts of common history?
- xn 4y ago
  main is a branch. By convention, it contains all of the commits back to an ancestor that has no parents. Unless given more information, I would consider the commits between `git merge-base main feature1` (exclusive) and feature1 (inclusive) as part of the feature1 branch. Now, if I `git checkout -b feature1-A feature1`, what commits are part of branch feature1-A? It depends. With respect to which merge base?

smusamashah 4y ago

Aren't git branches just linked lists in reverse? Since it's a reverse linked, you add to HEAD pointer instead of tail. And because it's reverse, you can branch out with any number of pointers (aka branches).

somewhereoutth 4y ago

I think of a git repo as a gigantic bramble bush, with some of the brambles joining back into each other. There are some labels attached to the bramble bush in various places. Some of the labels follow the tips as they grow, some stay fixed. It gets interesting when you compare two bramble bushes with the same provenance, see how they differ, and then how they can be reconciled.

throwbadubadu 4y ago

I want to argue... tags are that. Branches are usually ever changing and sometimes disappearing sequences of commits. ymmv (: (And now don't tell me that also tags could change, and branches not.. then we are almost back to it is all refs - btw why so mad about that? It is another valid viewpoint imo).

falseassertions 4y ago

I am sad that this article exists, let alone all this discussion. It feels like that sort of take that is put out there just to be contrarian and stir the pot. I don't think I've ever seen someone say "a branch is a ref" with the intent to diminish the concept of a branch or the utility of it, or the special language around it's concept. On the other hand, appreciating what git commits are, what tags are, what branches are, and understanding the "just refs" part of it, was vital to my understanding of git. This article feels like it argues against something that (1) doesn't exist, and (2) in the form in which it does exist, serves a vital role of exposing 'just enough' of git to help some folks understand the model enough to be effective with it.

GuB-42 4y ago

I am glad no one told me that because I would have caused me a lot of confusion. Git branches, the thing the "git branch" give you are pointers to a commit, or refs if you wish. It has several implications: you can move them at will, and after a merge, you lose track of what "sequence of commits" it originally was. I came to git from mercurial, and while they are fundamentally very similar, branches are a major difference because in mercurial, branches are really a named sequence of commits. Each commit of the branch is tagged with the branch name, and it will stay that way, even after a merge. You can't change or delete branches, only append to them or close them. Git-style branches also exist in mercurial and they are called bookmarks, so maybe you can call them that. Now there is the higher concept of branching that includes cloning and is not specific to git, and we can indeed call a branch a sequence of commits, but "git branches" have a precise meaning, and it is not that. Anyways, git is terrible at naming things, especially when it comes to its command line, one of the biggest flaws of an otherwise great version control system.

alexvoda 4y ago
Maybe the conclusion then is that when "higher concept of branching" means something, and other tools like mercurial align with that meaning, it is git that is wrong by using a different meaning. Git could have called their branches bookmarks too. If Bob insists on calling vodka "Bob water", and someone asks for some water to put out a fire and Bob gives them vodka, there is a problem even if "Bob water" has a precise meaning.

pcj-github 4y ago

A git branch is a text file containing a single sha1 value and a newline. Pretty sure the author can't tell me the named sequence of commits given that information.

sgustard 4y ago
A complex data structure is just a pointer. A file is just a pointer. My whole identity and personhood is just a pointer.

TeeMassive 4y ago

..that grows from the leaf

pictur 4y ago

someone who wants to experience hell can try to work in the same job with someone who has the same style as this blogger.

klysm 4y ago

My mental model is that a branch is a pointer to a commit, along with the other semantics of the git tooling that deal with branches. Specifically merge bases.

avgcorrection 4y ago

Don’t understand why this blog is featured so often on this site.