The most seemingly trivial design decisions in a software project can show who is not present as part of that project. And the absence of people in minority groups can result in decisions that exclude people in minorities from joining, in a feedback loop of self-reinforcing exclusion.
Git is a distributed version control system that has gained increasing popularity over the past few years, especially in free and open-source projects, despite a user interface widely regarded to be user-hostile. While most of the issues with git’s user interface are equal-opportunity annoyances, there is one that is specific to trans people who change their names, people who take or drop their spouse’s surname on marriage or divorce (who in Western culture are usually women), and the overlap between the two groups. Megan at “A Megahbite of Feminism” shows how the design choice to make the committer’s name and email address part of the data that determines the unique identity of a given commit can have a negative effect on women and trans people:
To try and put it simply, the author of a commit is tied in to the identity of the commit itself. If you change the author, it’s treated as an entirely new commit. Anyone who has grabbed a copy of your original commit and made subsequent changes on top of it finds themselves orphaned from the history of the project. To use a crude analogy, it’s like you rip the trunk of a tree out, while the branches are magically left hanging in the air, connected to nothing and isolated.
Of course, it’s not that the designers of Git tried to make it difficult for committers to change their names. It’s likely that most of them just didn’t think about what would happen if a developer needed to change their name retroactively, because most of the people who have worked on Git are cis men. They aren’t expected to change their names if and when they get married or divorced, and having cis privilege, they don’t need to change their name to something more consistent with their gender. Nevertheless, the inability to change one’s name retroactively without disrupting others’ work can mean that trans people — particularly trans women, who are likely to face harsh social stigma in any space where their trans history is known — will have to cease to contribute to their projects when they transition.
What other seemingly innocuous software design decisions contribute to exclusion?
Update: I’ve had to moderate a lot of comments for ‘splaining. When replying, avoid arguing from authority and keep in mind that other people have had experiences that are real even if you haven’t personally experienced them.
Second update: I’m continuing to moderate comments that are condescending or dismissive, because comments like that aren’t constructive and don’t create a useful discussion. Please familiarize yourself with our comment policy. Particularly, note that anonymous comments (those with an email address that can’t be tied to a consistent identity, such as anonymous mail services) are not permitted here.
Geek Feminism Blog 
Really interesting article! It’s just a side-issue but the parts about git’s user interface confused me – I think git just works from the command line, at least that’s how I’ve always used it – maybe it’s the code-sharing site github.com that has a confusing interface? (I could be completely wrong about this though.)
Yeah, I was just referring to the command-line user interface.
The article reminded me of:
http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
Totally agree in the part about transgender people name change but please remember that women changing names when they marry/separate/whatever doesn’t happen everywhere. I live in a country where women getting married change name, never changed mine and never got a problem with that.
There’s another identifier for the state of the software at a given state — detached from the history of who-did-what and in what order, but the tree ID is a person-neutral ID for that bit of state.
The concept of authorship is pretty important since one of the primary protections for software is copyright law, and tracking who is making changes is one of the important parts of that.
It really shows that git grew out of the linux kernel where tracking is really all that’s done to track who has copyright on the kernel. Other projects have different needs and different structures, but the software shows the origin in that particular one.
It’s not so much that it was a patriarchical origin as it was one where that was one of the paramount concerns, without regard to gender.
That said, the software is getting much better — if you were to rebase an entire tree and change all the commit IDs, but not the tree IDs, it can often (or even always, now) figure out that it’s the same history and handle the problem. It’s not pretty, it’s more manual than it should be, but it is possible to edit the chain of custody to change a historical identity.
We do need to encourage more pseudonymous authorship, though,
Falsehoods Programmers Believe About Names, especially number 7, is relevant here.
To me, this is another example of how diversity is simply a good thing. Somewhere along the line, there must have been someone who questioned this decision, and since it wasn’t a big issue to the people developing at the time, it never gained any traction.
Also, what’s the point of the user information in a source-code control system? Surely, (a) to tie all contributions by the same person together, and (b) to enable that person to be contacted if they permit it.
Allowing that information to be updated helps purpose (b). For everyone. How certain are you that the email address you have now will always be yours? Your provider might go under. You may decide to stop paying for that embarrassingly silly custom domain. You may disagree with your provider’s privacy policy, or reliability, or security, or pricing. Lots of reasons!
The only plus of keeping a historical set of info is cross-referencing with other contemporary documents which have not been updated to keep track of someone’s current name and address.
I think Linus’ motivation also involved tracking the copyright owner of a commit, since Linux was under legal attack at the time. If you@ibm pushes one commit and then you move job and you@sco writes another one, you don’t want to get the mistaken belief that SCO now owns the copyright on the previous commit too by changing the authorship history.
While this post was eye-opening in introducing me to a problem I hadn’t considered and am now sympathetic to, the lack of an alternative proposal is disappointing. Pointing out a negative consequence is not sufficient to show that the design decision was poorly considered: showing that there was an alternative with better consequences is. Can anybody think of one?
The best I can think of would be to extend “git notes” to allow amending commit messages as well as appending them. But this wouldn’t help much with the problem as stated for trans people, because the original commit messages (and therefore authorship) would still be available under the hood; “git notes” is an overlay on top of previous commits rather than a replacement for them.
If you read the comments on the original blog post, there are some solutions suggested there. This is computer science — adding a level of indirection shouldn’t be outrageous.
Just a note, when it comes to design decisions that have a disparate impact on people in marginalize groups, it is always okay to criticize those decisions even if one doesn’t have an alternative solution yet. Requiring an alternative solution in such a situation is a silencing mechanism.
A layer of indirection is not actually a solution, though. We could have any of the mechanisms proposed and we’d still be here, able to criticize the fact that git/whatever-PKI-tool-used-in-conjunction-with-it sends a “HEY THIS PERSON CHANGED THEIR NAME” message over the wire at some point, without having a workable solution yet.
Decklin: The thing about actually living these experiences, rather than just theorizing them, is that you already know that there is no perfect solution, and don’t need to be told that. It’s about harm reduction. It’s helpful to not have one’s commit history, which is something people read, scream “I’m a member of a socially stigmatized group!” Yes, that information is out there, but having more control over where it’s presented is important to people. When it actually affects your life, you can’t afford to dismiss a solution because it’s not perfect.
An interesting complaint but it is worth noting that this is common to any distributed version control system. I’d be curious if anyone has tried to implement a distributed system that can do this. Git and Mercurial don’t without rewriting the entire repository history and breaking compatibility with all other clones but doing that rewrite is actually pretty easy. I could see the possibility of a system that maintains revision history of commit metadata but it probably wouldn’t be easy to implement. Even then this wouldn’t help trans people trying to hide their previous identity since with versioned metadata the old name would still appear in the history.
Personally it seems reasonable that records of history are read-only since history is (at least until we get some time machines). But then I’m biased and can’t even keep track of my own friends’ name changes.
It’s one thing to be able to find a previous name if you look hard enough. It’s another to routinely see that previous name in past commits. I don’t see what purpose that serves; wouldn’t you want to see the same contributor name (the one they’re using now) for all their commits?
Yes, physical history is immutable, but that doesn’t mean everybody needs to leave all of their personal histories out in the open.
Is this not analogous to publishing anything under your name? Like a book or an academic paper or an article in any publication made from dead trees. That is the name of the person who published it, that name may not exist now (and the person may not exist) but at the time of the publication that was the byline. I guess retrospective name changes is a plausible feature of an online system, but it sounds like it would make the archive less trustworthy if there isn’t solid attribution (you could retrospectively assign commits to different people, or change everyone to be foo@example.com which would be hard to reverse). Technical challenges aside, how is this different to publishing an academic paper and then wanting to change the authorship information later?
This was commented on in the linked post — there’s no possible technical solution for updating an academic journal after it’s been published (you could still update the copy on the journal’s website, I suppose?), but there is a possible technical solution for updating digital information after the fact, so we shouldn’t use a limitation of the journal format as a reason not to try to do better in a format without that constraint.
Regarding changing everyone to foo@example.com, it’s not impossible to restrict the capability of making a name change to the identity that had the old name, and no-one else.
I agree that this argument over whether the history of digital information online should be considered immutable or modifiable seems much larger than just git, though.
@Alan Bell — This is no different from publishing an academic paper and then losing attribution when you go through the name change. That’s a real problem for women as well. When I changed my name, I knew that I was going to “lose” books and articles along the way, and it hurt. It’s nice, finally, that online databases are giving me the chance to associate *both* names with my work, so that my full accomplishments are easily discoverable. Men tend to assume stability of identity, and they forget that it’s a privilege rather than a right. For me, the point is that names are a poor identifier of achievement in cultures that insist on or encourage name changes in a large percentage of the population.
ok, thanks, this makes total sense, a slightly different use-case to wanting to withdraw a deprecated identity, but focussing on the continuity of identity across different names I can understand. It appears that this is an opportunity for digital systems to exceed the capabilities of traditional systems rather than an introduced shortcoming.
I support the points Tim is making.
If anyone thinks IP law/copyright concerns are valid resons for not changing anything, please research the concept of moral rights, which is a branch of copyright law: http://en.wikipedia.org/wiki/Moral_rights_%28copyright_law%29 Moral rights are part of copyright legislation in many countries (including mine, Australia) but are not law in the USA (due to political pressure from Hollywood, as my law lecturer explained).
Actually there is a way to link several contributions by .mailmap file. Why just commiting .mailmap file into git repo is not a solution? It looks like a solution designed to solve described problem…
it may be on the other site, but there’s an issue here that makes me think the cis-ness of this is rather overblown. no matter how cis you may be about your *name*, i don’t think anyone is about their *email address*. which isn’t really particularly subject to gender issues. it’s almost as likely to change for a privileged white male as anyone else. I can buy that Linus never thought about the case where his name might not be Linus Torvalds any more, but I don’t buy that he never thought about the case where his email address might change. It seems really unlikely that this is the way it is just because nobody ever considered the case where someone might want to change it; the email address change case just seems way too obvious.
Adam, the problem isn’t “not realizing that someone’s name might change” (as Alex R suggested above). The problem is not realizing that someone might want to disassociate themselves from a previous name — make a retroactive change — and that it might be a good idea to try to allow them to do this, instead of being a good idea to ensure that no-one can ever do this without breaking things, as git does.
So, the potentially-privileged assumption being examined is the one that says that it’s an error for someone’s name to change retroactively.
This kind of retroactive change is only plausible when historical records are kept on computer and not published on paper or in any other immutable form, so it seems that allowing history to change retroactively is a fairly recent possibility for us to consider as a society, and hasn’t been widely accepted as desirable yet.
(I’m not yet convinced that it *is* a desirable property with current technologies, because I don’t know that allowing retroactive name changes results in better consequences than disallowing them, given the potential for abuse via retroactive name change — someone could break the law in your name, take credit for your work, gain the level of trust that someone else has by impersonating them, etc. I hope the part of the comment threads that is investigating solutions will help make that practical side of the argument stronger.)
I understand why the ability to retroactively change names may be desirable and important, I’m not questioning that. I’m questioning the apparent belief that the committer ID is not changeable in this way because git was written by privileged males who would never have considered the need to change it because it doesn’t affect them.
My point is that the committer ID is not just a name but a combination of name and email address, and no matter how privileged you are as regards *name*, few people are privileged as regards *email address*. Ultimately my point is that the possibility of changing the committer ID was almost certainly considered and rejected for some specific reason, because the case of someone’s email address changing seems like something that would be obvious to anyone writing that code, regardless of gender etc.
It may still be the case that the reason for not making it changeable is applicable to the ’email change’ case but not the ‘name change for gender-related reasons’ case, and hence the decision should be re-considered. But it would probably be a good idea to consider it in that light – look back and see whether the possibility of changing the ID was considered and if so why it was rejected at the time, and take that into consideration in re-proposing that it be mutable. It’s always a good idea to look at why things are the way they are and take that history into consideration in proposing changes.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
Ah. I agree with you that it’s extremely normal for a male committer’s ID to change in a non-retroactive way — Linus has changed his committer ID ten times[1] since 2005.
I already gave my guess at what the rationale for making the decision to disallow retroactive authorship changes was elsewhere in the thread: recording copyright ownership of a patch in Linux correctly, since your previous employer continues to own copyright on your changes after you join a new company and get a new committer ID.
Since Linus designed Git to help him track Linux changes (and it’s a happy and surprising coincidence that it ended up winning the SCM wars and being generally useful), many of the design decisions come down to “what worked best for Linux?”.
[1]: git log –author=”Linus Torvalds” | grep “^Author:” | sort | uniq
The bit about recording copyright ownership seems like a red herring. I don’t know of any project that requires a copy of one’s government-issued ID to get commit access. There is already no guarantee that the names that committers use are their legal names.
[Sorry, this is meant to be a reply to Chris, but the thread depth was exceeded.]
A cis man is unlikely to experience social ostracism or sexual harassment, or be denied a job, because of a previous email address.
So what you’re saying is that although the technical problem is comparable (and the costs of the solution are basically equivalent), the benefit of solving the problem was/is underestimated (due to a lack of diversity of experiences)?
Right. It’s easy to overlook problems — or dismiss them as being non-problems, as I saw in many of the comments to this post that didn’t get past moderation — when they don’t affect you directly, or at least affect people you know or (at the very least) take seriously as people deserving of a decent life.
I ran into a similar problem numerous times in JIRA (which, overall, I love) Atlasian’s issue tracking system. Username is not editable, once created. That in combination with our company usernames first-initial+last name meant I had to create a lot of new accounts for people, all women, when they wanted a name change. It messed up our metrics, and I got a lot of “What?! Why?!” from the people it affected. I guess we could have made usernames not based on real names, but that would have been confusing to our users.
The problem is also that it takes the machine name as a default. A few of my commits to github happened under a wrong name because I have a spouse and a machine named after him. I wouldn’t call this design “patriarchal” (as it’s from the word “father” implying a family), but pure “bachelor”. A single person having a sole ownership over their property.
The term “patriarchy” is feminist vernacular. It refers to the systemic androcentric male supremacist built into every molecule of our existence. This approach demonstrates a software-planning perspective that never included people who will theoretically have to change their legal names as a use case.
Meaning, its use case only projected for MAABs (males assigned at birth) – and of those, only MAABs who do not experience sex-characteristic dysphoria. Behaving as if they’re the only sex on the planet is a classic example of the P in action.
> Particularly, note that anonymous comments (those with an email address that can’t be tied to a consistent identity, such as anonymous mail services) are not permitted here.
This seems kind of ironic. For a long time, one of the few old pictures under my name was tied to a blog comment I couldn’t figure out how to deal with.
Gravatar makes that situation somewhat better, but also somewhat trickier if you want to keep an old e-mail address but drop old names/stuff attached to it.
I mean I get the reason for the idea, but to some extent I’ve always felt that stringent identity mapping requirements did make some spaces I should feel welcome in, feel more hostile than they probably should.
Not sure if this post is off topic, or on-topic. I think maybe a little bit of both.
A consistent identity doesn’t have to be an identity that’s used anywhere else. Someone could make the email address “Geek Feminism Comments: Fuchsia Lawnmower <geek_feminism_fuchsia_lawnmower@anywhere.org>” and that would be fine. It’s just a completely anonymous identity like “Anonymous <anonymous@mailinator.com>” that the comment policy discourages.
I think it’s okay to require this (low) level of non-anonymity because it encourages community and discourages drive-by, one-time comments from someone who just wants to throw a handful of anger and not be an ongoing participant.
If I understand this correctly (and I believe the referenced article even said this), the commit key includes the user’s name and E-mail address.
I’m having a really hard time understanding why this sort of thing would be a good idea. While I can’t say I’ve used an enormous number of version control systems, the main point of a key is to (a) give a unique identity to a version of something and to the extent practical (b) make visible the relationship between versions.
Why the identity of the user doing the commit helps with either of these goals I just can’t see. If anything, it would be confusing. In all my work environments, any particular project may be handled by a bunch of different people, so one change may be made by one person, the next in the chain by the next, and so on.
As for name changes, the company I’m at isn’t consistent as to what a person’s name is. E.g., my chinese co-workers typically have a Chinese name and an English name, and which name you look them up by depends upon the whim of whoever handled the last DB migration. (In mega-big-corporations, this happens at least once a year.) And you don’t have to be Chinese — my co-worker has been switched between “Kathy” and “Katherine” several times.
I would think it would make more sense to regard this as “auxiliary” information, like the commit comments (I hope Git uses commit comments!) or the location where the commit was made from.
This problem shows up in a surprising number of places- the CPAN for instance, does not have facilities for changing a CPAN ID, and I had to create a new account. (Something I note that other Perl trans-folk have also done.)