Live data from Hacker News

Artisanal handcrafted Git repositories

drew.silcock.dev

51–60 of 74 posts

Re: Artisanal handcrafted Git repositories

#51

Am I the only one having troubles with the site on mobile? I'm using Firefox on a decent Android phone but the scroll is extremely stuttery and it distracts from the article unfortunately.

The site is built with a content creation tool which has used a lot of JS and CSS, but the CSS is atrocious in it's automated output so it's triggering the browser to have to interpret the mess of directives in every code block. The tool is generating HTML trash like (brackets replaced for comment to not parse):

    [span style="--0:#E1E4E8;--1:#24292E"] [/span]
...over and over, essentially giving style directives for every blank space in the code block. A less capable mobile CPU may well have issues rendering this site due to the presence of so much trash CSS inside it guts. $0.02 hth

Re: Artisanal handcrafted Git repositories

#52
post #17

I thought this was going to be a sardonic article about doing programming without LLMs.

I'm starting to see this kind of wording as a unique selling point, that some software (or article, visual art, etc.) is handcrafted and artisanal, as opposed to AI-generated. "Every word was written by me, a human being!" At this point in the emerging technology I can usually tell the difference intuitively, but it's possible that one day it will be indistinguishable - and the quality of "handmade" will be simply a…

Homegrown bugs from sustainably raised Bio-certified devs vs industrial bugs.

Re: Artisanal handcrafted Git repositories

#53

Okay, there's something I have been thinking about recently. Is it possible to somehow make Git use the Content Defined Chunking algorithm from rsync? Maybe somehow using clean/smudge? If not git, then maybe Mercurial, Fossil or any other DVCS? This would help with large binary assets without having to deal with the mess that is LFS, as long as the assets were uncompressed.

IIRC it already uses content defined chunking for finding object deltas.

Re: Artisanal handcrafted Git repositories

#55
post #16
post #2

To the site author: I'm on a MBP M1 Mac and honestly I can't really read the text. Far too small, and increasing the zoom just makes the text large but the margins less wide. Firefox reader mode also renders really badly. Please, consider making the layout better for us old coders whose eyes are going, or for hi res displays

FYI: the pinch-to-zoom gesture from mobile browsers (from before websites were mobile-responsive) has also long been implemented for all modern desktop browsers. It's viewport zoom, which is far better than the font-scaling zoom you get by pressing Cmd-+, and makes this site easily readable. (The much-less-well-known mobile double-tap-on-text gesture [it zooms-to-fit whatever element you tapped on to the width of the…

FWIW, most browsers by default now do a viewport zoom with Ctrl/Cmd-+ rather than a font-scaling zoom. I think browsers generally have the option to change that, so if you prefer the former but it's doing the latter, may check the browser settings.

Re: Artisanal handcrafted Git repositories

#56
post #47

Earlier quoted context omitted.

> directory tree entry names But... git doesn't really store directories, does it?

Yes it does, it just doesn't store empty directories.

You can perfectly easily put the empty tree object as a tree object's child, this just isn't supported and some parts of Git will break.

Re: Artisanal handcrafted Git repositories

#57
post #47

Earlier quoted context omitted.

> directory tree entry names But... git doesn't really store directories, does it?

Yes it does, it just doesn't store empty directories.

It can store empty directories (actually, trees). It can't do normally because the index maps paths to blobs, an empty directory doesn't have a file to map to a blob and then `git add` will have no effect. Given that normally we write commits from the index content, then normally we won't find an empty tree.

You can run `git commit --allow-empty` with an empty index and the root tree will be the empty tree:

   $ git init
   $ git commit --allow-empty -m foo
   $ git rev-parse @^{tree}
   4b825dc642cb6eb9a060e54bf8d69288fbee4904
4b825dc is the empty tree. And a funny thing about it is that it is hardcoded in Git, and you can use it without having this object:

   $ git init
   $ git commit-tree -m foo 4b825dc642cb6eb9a060e54bf8d69288fbee4904
   $ tree .git/objects # you'll see that there's no file for the empty tree
This is a good reading about that weird object: https://matheustavares.dev/posts/empty-tree

Re: Artisanal handcrafted Git repositories

#58
post #45

Earlier quoted context omitted.

> directory tree entry names But... git doesn't really store directories, does it?

I wrote a longer comment saying this (deleted now since I was wrong). Turns out that Git does somewhat store dirs (in form of trees). See https://git-scm.com/book/en/v2/Git-Internals-Git-Objects (section "Tree Objects"). To understand op's repro look at the last two lines (objects in the tree) in each of their command outputs, not the files shown in the first few lines. What I think op means is that the `testing` tre…

> This makes me wonder why Git can't just store an empty tree for empty dirs.

tl;dr: it can (see my other comment) and the empty tree is hardcoded. But since the index works with file paths and blobs, having no file means that there's no entry in the index

Re: Artisanal handcrafted Git repositories

#59
post #2

To the site author: I'm on a MBP M1 Mac and honestly I can't really read the text. Far too small, and increasing the zoom just makes the text large but the margins less wide. Firefox reader mode also renders really badly. Please, consider making the layout better for us old coders whose eyes are going, or for hi res displays

For me, the text size would be fine if the contrast were better. The background colour is similar to the colour of the non-central pixels of the text, and even the central pixels are grey rather than black.

Re: Artisanal handcrafted Git repositories

#60

Earlier quoted context omitted.

There aren’t that many weird states a git repository can be in: the on-disk format of the repository is too simple for that. The hard part has to do with the various protocols for transferring objects around.

I think there's more corners out there than most people would give credit to? Just off the top of my head: files in the index (but maybe this isn't "weird enough"), rebasing but paused, rebasing with conflicts, merge with conflicts, cherry-picking but conflicts, middle of a bisect with all the state that implies, alternate objects dirs, alternate working dirs, submodules and all of their weirdness, and a "bare" repo.…

I knew .git can be a normal file because of worktrees. But most of the weird states have to do with the working tree not the repository. Even rebasing isn’t weird as far as the file formats go: it just is replaying commits on top of a new base commit. Since my goal was basically to implement enough of git to serve files from a git repository as a website, the actual task was fairly small.
Post reply on HN