Git Branches as a Social Construct | Hacker News Reader

Git Branches as a Social Construct

utcc.utoronto.ca

69 pointsingve76 comments

This is a terrible use of the phrase "social construct". What things are vs what things are used for is not interesting by category, only in the specifics. Hammers are a social construct, because some people use them for nails, and some people use them to bash other people's heads in.

I don't think that's a good analogy. Hammer would be a social construct if some group of people used "hammer" as a technical term for the tool and another group used the word "hammer" specifically for tools used to hit someone. In your example everyone agrees about what a hammer is, they just use it for different purposes. That is not as interesting to analyse.

The distinction between the uses is important, because you may end up talking to one of the groups and not realise you're using the same word for different things.

Sorry to hammer the point home, but I'm not saying "words can't have different meanings". I'm saying it's not useful to rename "meanings" as "social constructs".

You're missing a specific property where social constructs need to not exist without people agreeing they exist. It's not just about the multiple meanings - it's a social construct if it didn't exist before. "hammer" did exist. "hammer as a description of tools used to hurt people" doesn't until people agree it does.

The interesting parts are that enough consensus emerged due to (some factors) to create that meaning, how did that consensus emerge, if it's isolated to some groups, etc.

> What things are vs what things are used for is not interesting by category

On the contrary, this is the entire field of UX design, and quite a large chunk of material anthropology.

At some level everything we relate to is a social construct, once we use it to discuss things with other humans. A computational linguist friend of mine once wrote a long LJ post on "Ether is a social construct" after spending his PhD extracting chemical information from papers. His point was that ether, like various acids and other substances, behaves differently at different concentrations, in ways that are important for reactions but must be inferred from context and prior knowledge of chemistry. In other words, technical terms are more precise than everyday language, but are rarely fully precise because they cannot capture all the context in which they are used.

Abstraction is not the same as social construct. A branch as a term is very much a part of git porcelain (which is an abstraction of the plumbing, ie: the 'git branch' command exists), it's not just some term that organically evolved and was agreed upon by convention. Furthermore, the meaning of it isn't going to further evolve into something different as people learn more about it. Unlike social constructs

Have you seen the different git branch development strategies?

Some places use branches for versions instead of tags.

Some places religiously follow git flow’s branch rules.

Some just have a master production branch and feature branches.

Some have staging branches too.

In this way, branches become a social construct, as the use (and thus meaning) of a branch can change from organization (eg, small social circle) to organization.

Sure, so a development process is perhaps a social construct (or rather, using the term scocai construct to describe a development process is not entirely incorrect).

However, the idea of a git branch exists independent of the manner a certain population agrees on its use. It doesn't cease to exist just because you haven't agreed on how to use it.

> idea of a git branch exists independent of the manner a certain population agrees on its use.

No! A set of bits exists on disk. A piece of software (git) interprets those bits as a branch. The idea of a branch exists in the heads of the users - subject to the usual human limitations. While quite a lot of users will be able to be precise about what a branch means in terms of git blobs, there will be people using the tool and talking about branches who don't know that. But an idea, whatever it is, exists only in the way that people think and talk about it.

Even in this thread we have people fighting about what it is: https://news.ycombinator.com/item?id=38999486

> A set of bits exists on disk

That's just what society's conditioned you to think.

> No! A set of bits exists on disk. A piece of software (git) interprets those bits as a branch

I call what you describe there an abstraction. So, feels like I'm going full circle here to my original comment.

My (possibly incorrect or incomplete) understanding is that abstraction is when some complex underlying mechanism is presented in a manner that serves a specific purpose. In essence the difference between an abstraction and a social construct is that an abstraction deals with simplification of ideas and presenting them in a manner that makes it easy to interact with them.

While social constructs are about shared understanding of ideas regardless of whether these are reified in any manner or whether there is are ways to interact and engage with them.

Abstractions only _really_ exist in your mind as all abstractions (at least in software) are implemented with the lower level of that abstraction (which itself is an abstraction and so on)

So it could be argued that the abstraction isn’t _actually_ different than the sum of its lower level parts. It’s your understanding as a human (potentially and probably shaped by your society) that makes the abstraction easier to understand than the lower level bits.

A shared understanding (at least between an author of an abstraction and the lower level components it’s built from) is required for a software author to make any abstractions anyway.

> At some level everything we relate to is a social construct, once we use it to discuss things with other humans

This is exactly what I disagree with. If you do s/meaning/social\ construct/g then by that definition you're correct, but you're ironically creating two meanings of social construct: one useful one (the original), and one confusing one (that sounds like the original, but is equivalent to "meaning" or "semantics").

Par for the course. I don’t think I have ever seen the use of the phrase “social construct” which wasn’t terrible.

Yeah, it's usually a cliched pseudo-sceintific way of saying "I don't think it's necessary", and that seems to be the case here too.

...and some people use them to describe things you can't touch (ba dum tss)

I don't know if the author uses the term intentionally, or as a kind of parody. The "social construct" term has been applied over and over to many phenomena in different branches of human knowledge, mostly to produce plenty of confusion resulting from "everything is everything" kind of situation.

The humanities are, probably, the most avid user of this term, and that's why the irony. I.e. because we couldn't find a decent definition for what "race", or "ethnicity", or "culture", or "country" etc. is, every such problematic term was labeled a "social construct".

So, I think you might be too harsh on the author. I doubt they use "social construct" completely unironically. What they are actually trying to say is that "there's more to branches than meets the eye, and it turns out that it's hard to define what a branch actually is".

Yes, humans use terminology to describe abstract concepts. This terminology often has nothing to do with the actual inner workings of this abstract concept. Everything is a social construct.

Makes one wonder what the purpose of calling something a social construct is, if everything is one.

Generally, there isn't one.

To separate it from natural constructs. Specifically, to counter claims that certain social constructs are natural constructs.

Societies are naturally occurring, so all social constructs are natural constructs and all natural constructs are social constructs. None of these terms mean anything.

You're looking at it wrong. We can't change the laws of physics, but we can change society. That's the practical difference.

The 'laws of physics' are a model that change all the time through a process known as 'science'.

Have you not read Latour. Scientific facts such as the laws of physics are socially constructed.

Everything in the universe is composed of atoms, therefore nature doesn't exist, the term doesn't mean anything. What are humans but a collection of atoms?

And yet, despite nature being composed of atoms, we can speak of nature. We can speak of humanity, despite humans being primates, and we can speak of civilization, despite other primates not being capable of civilization. Language is merely breathing and moving the tongue, yet choking is not language. Water is not hydrogen peroxide despite both being composed of hydrogen and oxygen.

Not every reductio ad absurdum argument succeeds in disproving the value of the abstraction it seeks to deconstruct. All social constructs are not natural constructs in the sense that "natural" is being employed here. Capitalism is not defined by the laws of physics. Animals don't practice capitalism. Capitalism is a "natural construct" in that we humans are biological entities and therefore a part of nature, but capitalism is not a natural construct in the sense that it is defined entirely by physical law or immutable biological instinct. The context matters.

These terms do have meaning. The fact that you can attempt an argument based on their semantics, which differs from simply pounding random letters on the keyboard, demonstrates that they have meaning.

You claim they have meaning but you made no attempt to define either.

To remind ourselves that this is the case

> Everything is a social construct.

Well if the abstraction is invented by a lone programmer who doesn't want to write documentation, is it a social construct?

Probably not -> social construct is just the wrong term.

Feels comparable to how folders in file systems are there for the user to make sense of it, but technically they work in ways that easily break that mental model.

That's interesting, in what ways do directories break the mental model?

Folder, not directory. Try nesting these inside each other: https://www.amazon.com/Pendaflex-Folders-Classic-Positions-6...

I mean, maybe everyone here is so used to the word, but try nesting these inside each other: https://www.amazon.com/Classic-Address-Phone-Directory-Refil...

Since directories are just references that tell you where a resource is located and don't actually contain the resource, that's not very difficult.

We don't usually put directories inside other directories though.

For "normal" people they represent a unique and finite set of files under a specific hierarchy.

The technical implementation allows us to put the same files in as many folder as we want, folders recursing on themselves, "smart folders" that don't have any stable set of files, remotely synched folders etc.

The hierarchy model means that they're not suitable for some uses that the technology could support. If I have a picture of my family member and my dog, I don't want to put them exclusively in a 'family member' folder or 'dog' folder. I ideally want a hard link in both, but that's not trivial. This sounds silly - people generally name their folders by event rather than like tags - but that's a consequence of the interface rather than an inherent quality of storage. In reaction to this & us rapidly having more personal media and files, we're now seeing a shift towards interfaces that treat the entire filesystem as a flat, searchable index - including indexing that recognises the family members and pets.

> I ideally want a hard link in both, but that's not trivial

Yes it is. First put the file in one folder, and then make the hardlink in the other.

Trivial step 1: open Powershell with elevated permissions.

I just looked it up, and while you apparently do need evelated permissions to create a symlink on Windows (???), I think you don't need elevated permissions to make a hard link. So really your step 1 is "open PowerShell".

So the only reason it's not "trivial" is because you don't happen to always have a terminal window open.

Personally I do almost all of my file management from the shell.

Terminal windows are not well integrated into things like file pickers and download windows. Even if power users use them, they're not used by most people and aren't part of the common, low-friction UX.

Yes. I see gmail's approach of maskerading tags as folders as really genius.

It's simple enough, until the user hits the limits, start wanting more and and discoves that there's no limit and they can actually do more.

I think Folders are more an example where neither the technical implementation nor the mental model fit the real world particularly well (in the general case).

That's where a spatial file manager comes in!

It's a Unix system! I know this!

Clever girl!

This article resonated with me be because I have also thought of branches as something ephemeral, with the ultimate goal of packaging and delivering a change to "prod". Perhaps this has to do with the fact that I have mostly worked on projects that have the concept of "prod".

The "what is a branch" question has been very interesting for me for a while. One alternative way of looking at it is as just semantic groupings as opposed to separate universes. For almost a year I have been working on an idea[0] of having multiple branches applied in the working directory at the same time. Why? To make it easier for me to organise my changes in small PRs (eg. bugfix, featureX, unrelated refactors etc). If anyone reading this is also into the 'what is a branch' question, I would actually like to get some critique / feedback & opinions

[0] https://docs.gitbutler.com/features/virtual-branches

I don't understand why people get so confused and wound up about this - yes a branch is just a ref; yes something can be 'on a branch', by which we mean 'in that history'.

Well there is some tool that provides some functionalities, and surprise surprise the technical details of how they are implemented is not a mirror image of the set of functionalities ! I don't think that makes it a social construct but rather an abstraction made up by the creator of said tool to achieve their goals. Sometimes the abstraction gets a bit leaky as is the case with git, which makes things confusing and messy, but abstraction is in most things in computing.

Git itself is of course a social construct. It was invented to allow people to collaborate on code and have history and verify each others work. The compiler doesn't care.

It's a collection of tools (commit, branch, merge, rebase) facilitating decentralised ad-hoc workflows. It's less of a VCS and more of a hacky diffing tool.

This isn't how the term is used... Since recently (think something like the 60s), applying the term "social construct" became a practice, especially common in humanities because a lot of concepts previously used in that area turned out to be bogus / ill-defined.

For example, in anthropology, there was a shift where ethnicity used to be defined in some way (let's not dwell on the details, they certainly were problematic), and then someone came and said "well... ethnicity is a social construct", by which they meant "you can call this ethnicity, but I may call that other thing ethnicity, who knows what ethnicity really is... but as long as a large enough group of people agrees to use the term consistently, we are good".

And this approach to definitions keeps spreading. Some such claims become more contentious because they may run into religious orthodoxy or social conservatism that like to hold on to older (but usually not so great) definitions. Like, for example, some will claim that "gender is a social construct" meaning that beside biological gender, society can invent any number of genders it likes, as long as people agree to accept those and perceive them as "real".

But, regardless of whether you use "social construct" ironically (as to make fun of humanities majors) or actually believe it's a good way to proceed with definitions... I don't think you have anything to gain from claim that Git is a social construct. This is really only useful if you were struggling to define what Git is, and then there'd be groups of people who had competing definitions.

True, I am just going along with the “Git Branches as a social construct” as a given.

Git is not merely a social construct, it is a veritable smorgasbord of of patriarchal, colonial, and capitalist structures. Branches are instruments of colonial exploration and exploitation, which facilitate the integration new code territories into repository empires. Merges symbolize the enforcement of a hierarchical order, patriarchally assimilating code into dominant “master” norms. Commits, as quantifiable units of productivity, enable the capitalist class to separate the worker from the means of production.

(…and don’t get me started on stashes. Private property is inherently theft.)

The only way to upend the oppression of Git is through Subversion!

Git supports having people work on the same project at the same time in an uncoordinated fashion. That's literally all branches are.

Everything is a social construct these days.

Programmers seem to have little (or only moderate) problem with pointers and references in programming languages. With the occasional bug here or there with things like using `==` on `Integer` (Java). But bugs aside: they get what it is about. But when this is used in Git it becomes a sort of philosophical conundrum? Like huh, what is the ontology of a branch vs. the phenomenological nature of it. I don’t get it.

Git is a crude tool that exposes reference semantics to its user. In general, even programming-oriented tools like IDEs don't do that. Suppose you had to configure an IDE or a build system by creating chains of references and occasionally putting "fc8d43" to join disconnected sub-trees.

`git push -f` and solipsistic shared reality; when you `push -f` everyone gets to vote on what chain of commit hashes is the real ${orgname}/${reponame}//${branch}

There is no formal consensus mechanism beyond push permission in git itself; and so what would be regressive centralization of technically decentralized [git] in order to enforce directory-level permissions like e.g. CODEOWNERS is actually necessary for quality control.

Eventually, Github and Gitlab integrated code review like ReviewBoard and Gerrit (instead of mailing list patchbombs and quilt); and code review approval from zero one or more authorized reviewers is now an optional necessary precondition for merging to a git branch as a social construct.

DevSecOps says, Pull Requests (or Merge Requests) are merged only when (1) all of the automated tests pass; and (2) enough necessary reviewers have indicated approval.

Git doesn't tell you when it's necessary to have full test coverage and manual infosec review in development cycles that produce releases, and neither do Pull Requests.

https://westurner.github.io/hnlog/#comment-19552164 ctrl-f hubflow

It looks like datasift's gitflow/hubflow docs are 404'ing, but the original nvie blog post [1] has the Git branching workflow diagrams; which the wpsharks/hubflow fork [3] of datasift/gitflow fork [2] of gitflow [1]has a copy of in the README:

[1] https://github.com/nvie/gitflow

[2] https://github.com/datasift/gitflow

[3] https://github.com/wpsharks/hubflow?tab=readme-ov-file

https://learngitbranching.js.org/ is still a great resource, and it could work on mobile devices.

The math of VCS deltas and mutable and immutable content-addressed DAG nodes identified by 2^n bits describing repo/$((2*inf)) bits ;

>> "ugit – Learn Git Internals by Building Git in Python" https://www.leshenko.net/p/ugit/

SLSA.dev is a social construct atop e.g. git, which is really a low-level purpose-built tool and Perl and now Python porcelain.

jj (jujutsu) is a git-compatible VCS CLI: https://github.com/martinvonz/jj

"Ask HN: Best Git workflow for small teams" (2016) https://news.ycombinator.com/item?id=12941997

How much social construct atop git is necessary for e.g. the CPython project?

Python Devguide > Getting Started > [ Git bootcamp and cheat sheet , Lifecycle of a pull request ] https://devguide.python.org/getting-started/

Python Devguide > Development workflow > Development cycle > Branches: https://devguide.python.org/developer-workflow/development-c... :

> [ In-development (main) branch, Maintenance branches, Security branches, End-of-life branches ]

Git branches have lifecycles.

git isn't the entirety of version control. Branches existed before git and are a concept that exists independent from git.

If what git calls branches is not very good at handling the general concept of branching that is an issue with git's model of it. People shouldn't redefine what branches are to be whatever git does because that assumes what git does is right.

Git branches are about as real as the most significant bit in an IEEE 754 double's significand.

> modern version control systems are a user interface to their underlying mathematics

Widespread (mis)understanding of Git is a direct result of programmers who don't understand library and information science refusing to accept that they're in the domain of library and information science but trying to slog through anyway without the prereq; repo operations comprise an algebra of publishing. It gets really perverse in interdisciplinary settings when technical folks start trying to explain Git to people in the humanities who are better equipped to grok its fundamentals than the average programmer.

That's an interesting POV. Are there papers or other research that have been published by professional librarians regarding git and similar repository systems in use by the software development community?

Sorry, I'm not steeped in that world (unlike some of the more presumptuous and clearly self-serving comments surrounding yours have evidently assumed), and I don't know of any; my background is a programmer with a formal education in CS. I wouldn't be surprised if the answer were, "There aren't any." cf Feynman:

In this age of specialization men who thoroughly know one field are often incompetent to discuss another. The great problems of the relations between one and another aspect of human activity have for this reason been discussed less and less in public.

That's very snoby-sounding tbh.

Why would the average humanities person be better equipped to understand an algebra about source code management? What a weird take. It's not about managing a library of any kind, it's about a tree of changes. And it's not (only) about publishing either.

Is there a reason why between what I originally wrote and what you wrote here, you changed enough of the words that it no longer matches what I actually said?

> It's not about managing a library of any kind, it's about a tree of changes.

No, a Git repo is not "a tree of changes" (nor is Git a "hacky diffing tool").

Just because you frame Git to be a certain way, doesn't mean I agree with it.

Define Git for me then please. Obviously we're using very different tools. Git itself, for me, manages diffs (or rather refs of diffs) as a tree. Branches are pointers. That's it.

/e: and why on earth is it an algebra about publishing? As I said before, imho it's not about publishing, but about tracking. Publishing is just an aspect.

> Define Git for me

I'll pass.

> Git [...] manages diffs (or rather refs of diffs)

Wrong.

> why on earth is it an algebra about publishing?

It's not. I said operations on a repo comprise an algebra of publishing. As for why? Because that's what we're talking about: the stupid content tracker. This is not disputable.

> As I said before, imho it's [...] about tracking

You didn't say that. And you were less than humble about what you did say.

Thank you for showing me that any time spent on talking to you is wasted. You clearly demonstrate that you have no interest in a discussion.

Again, not true. But discussion with you? About this? Here? Bang on—I can't see any upsides.

This self aggrandization by humanities people never gets old.

Git is a DAG management system. It's fine if you don't understand what that means.

The world runs on science and commerce, get down your humanities high horse.

Oh boy. I'll take "Motivated Reasoning" for 50¢, Ken.

> when technical folks start trying to explain Git to people in the humanities who are better equipped to grok its fundamentals

Maybe we need some librarians to explain to us what "updates remote refs using local refs, while sending objects necessary to complete the given refs" means :-)

Your argument for why librarians (sic) aren't equipped to understand and provide instruction on the theory of content tracking is a well-known example of subpar documentation written by a programmer?

Can you expand? I'd like to see an example of the kind of disconnect you're thinking of. Or even better, a library-sciencey model of version control.

It's interesting how many mental models of git there are. For me it's a digraph (specifically a DAG, unless you've done something horribly creative). For other people it's a patch-management tool. Or a versioned database. It seems like almost nobody thinks it's a source code repo.

I would like to hear more.

Check out his other comments. He responded to every single person except the two who said they'd like to learn more about this.

Reply on news.ycombinator.com