Post #2349209

2025-12-02 17:04 UTC

here are some things I learned while writing this: 1. Commits can have "extra fields", for example a GPG signature 2. I always thought entries in a tree had 4 fields, but there are actually only 3 (file name, file type, and object ID) 3. Git sometimes prints out file types as a bit set (100644), but it's really more like an enum, since there are only 5 file types (regular file, executable file, symlink, directory, and gitlink) (2/?)

Replies (6)

@b0rk@social.jvns.ca 2025-12-02 17:15

4. In Git's index (aka staging area), every file has a "stage number". This is usually 0, but when there's a merge conflict then there can be 4 versions of the same file in the "staging area" 5. Branches are not necessarily always stored as "every branch is a file in .git", there's also a reftable backend https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/ which fixes some problems with "branches are files", like how if you're on a case-insensitive filesystem it means your branches are also case-insensitive (3/?)

Open ##2349210
@enhancedscurry@mastodon.social 2025-12-02 17:08

@b0rk@social.jvns.ca I don't think git has any native recognition of directories. It just knows about paths. Or at least you cannot commit an empty directory.

Open ##2349212
@dgelessus@mastodon.social 2025-12-02 20:46

@b0rk@social.jvns.ca The way Git displays octal file modes to the user is so unfortunate :( It gives you the false impression that files in a repo *could* have unusual permissions/types, or that perhaps the umask on a commiter's machine might affect the permissions of newly committed files, whereas in reality Git enforces "standard" file modes. (To be clear, I think it's good that Git can't store any fancy permissions/types - I just wish it would communicate that to the user...)

Open ##2349217
@bartavi@mastodon.nl 2025-12-02 21:20

@b0rk@social.jvns.ca What did you think would be the fourth field of a tree entry?

Open ##2349219
@esoteric_programmer@social.stealthy.club 2025-12-03 01:40

@b0rk@social.jvns.ca what's a gitlink? I never heard of that one before

Open ##2349221
@Exagone313@share.elouworld.org 2025-12-03 21:01

@b0rk@social.jvns.ca Hmm, are those extra fields stored in the commit itself or can arbitrary metadata be stored in Git? For some context (and it might have been experimented on already), Mercurial has an extension called evolve that is providing "obsolescence markers", which are pushed (and pulled) in the remote repository. Those obsolescence markers let you know when a commit was rewritten in history, e.g. after a rebase or after modifying it, and this is used to automatically "evolve" a branch modified by your peers (and also for the server to forbid pushing outdated changes, like with force-with-lease). I'm wondering if evolve could be ported to Git.

Open ##2349223