81–90 of 240 posts
When are we moving to SHA256? Some code bases must be getting massive by now sfter 20 years,
Earlier quoted context omitted.
> The GUID can certainly be a hash. It can’t be, because a GUID is supposed to be a globally unique. The point is, it needs to instead be the hash of the content. This can’t be an afterthought.
UUID versions 3 and 5 are derived from hashes (MD5 and SHA1 respectively).
There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…
Earlier quoted context omitted.
This is exciting, convergence is always good, but I'm confused about the value of putting the tracking information in a git commit header as opposed to a git trailer [1] where it currently lives. In both cases, it's just metadata that tooling can extract. Edit: then again, I've dealt with user error with the fragile semantics of trailers, so perhaps a header is just more robust? [1] https://git-scm.com/docs/git-inter…
Mostly because it is jarring for users that want to interact with tools which require these footers -- and the setups to apply them, like Gerrit's change-id script -- are often annoying, for example supporting Windows users but without needing stuff like bash. Now, I wrote the prototype integration between Gerrit and Jujutsu (which is not mainline, but people use it) and it applies Change-Id trailers automatically to…
While you're around, do you know why Jujutsu created its own change-id format (the reverse hex), rather than use hashes (like Git & Gerrit)?
Earlier quoted context omitted.
UUID versions 3 and 5 are derived from hashes (MD5 and SHA1 respectively).
GUID and UUID are different.
Tremulous (ioquake3 fork) had GUIDs from qkeys.
https://icculus.org/pipermail/quake3/2006-April/000951.html
You can see how qkeys are generated, and essentially a GUID is:
Cvar_Get("cl_guid", Com_MD5File(QKEY_FILE, 0), CVAR_USERINFO | CVAR_ROM);
> On startup, the client engine looks for a file called qkey. If it does not exist, 2KiB worth of random binary data is inserted into the qkey file. A MD5 digest is then made of the qkey file and it is inserted into the cl_guid cvar.
UUIDs have RFCs, GUIDs apparently do not, but AFAIK UUIDs are also named GUIDs, so...
Earlier quoted context omitted.
UUID versions 3 and 5 are derived from hashes (MD5 and SHA1 respectively).
GUID and UUID are different.
Earlier quoted context omitted.
Yes, but the commit object (which includes metadata) references a tree object by its hash. The tree object is a text representation of a directory tree, basically, referencing file blobs by hash. So yes, you can recognize identical files between commits. It's true there's no fast indexing: if you want to ask the question "which commits contain exactly this file?" you have to search every commit. But you don't need to…
but people don't use the file hash, that's internal to git. I go to the centralized repository of repositories at github.com and look up tagged version 1.0.0 of whatever software, which refers to a git tag which references a commit hash (which yes it references a tree object as you said).
And in any case you had a specific requirement above ("Given a collection of files, but not the git repo they're from, and libgit, I can't say if those files match a git tag hash"), and in fact this can be done!
> I would love to do a whole blog post about how mailing list collaboration works and how cool various aspects of it are, but that’s for another time. This is actually the part I would be interested in, coming from a GitHub cofounder.
You'll be the first to know when I write it. However, if anything, GitHub sort of killed the mailing list as a generally viable collaboration format outside of very specific use cases, so I'm not sure if I'm the right person to do it justice. However, it is a very cool and unique format that has several benefits that GitHub PR based workflows really lose out on.
Earlier quoted context omitted.
I'm curious why you think hg had a prominent role in this. I mean, it did pop up at almost exactly the same time for exactly the same reasons (BK, kernel drama) but I don't see evidence of Matt's benchmarks or development affecting the Git design decisions at all. Here's one of the first threads where Matt (Olivia) introduces the project and benchmarks, but it seems like the list finds it unremarkable enough comparat…
[flagged]
For the deadnaming comment, it wasn't out of disrespect, but when referring to an email chain, it could otherwise be confusing if you're not aware of her transition.
I wasn't sponsoring hg-git, I wrote it. I also wrote the original Subversion bridge for GitHub, which was actually recently deprecated.
https://github.blog/news-insights/product-news/sunsetting-su...
Earlier quoted context omitted.
NixOS may end up being "the last OS I ever use" (especially now that gaming is viable on it): https://nixos.org/ Check it out. The whitepaper's a fairly digestible read, too, and may get you excited about the whole concept (which is VERY different from how things are normally done, but ends up giving you guarantees )
The problem with NoxOS is all the effort to capture software closures is rendered moot by Linux namespaces, which are a more complete solution to the same problem. Of course we didn't have them when the white paper was written, so that's fair but technology has moved on.