Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

20 years of Git

blog.gitbutler.com

Post reply on HN
Print view View original

211–220 of 240 posts

Re: 20 years of Git

#211

Post by ajross »

fragmede wrote: post #178
ajross wrote: post #87

Earlier quoted context omitted.

"People" don't commonly use them, no. But it's a real and documented API to do this (see e.g. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects ). 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!

The git tag hash references a commit. Without the commit metadata, you don't have a tree object and thus don't know any hashes. You can take the files on disk and compute the hash and furthermore you can take that hash and make a tree object. but without the commit, all you can say is you have a tree object, you don't have a tree object for the commit in question to compare it to.

Read the link. You can extract the commit object and get the tree ref trivially. You can also enumerate commits (literally what "git log" is for). The only thing missing from the process is a fast reverse index going backwards from blob to tree to commit. But that can be generated in just a few seconds even for the largest repositories (16s to do a full git log of Linux on my box, for example).

I'm at a loss. You keep saying something can't be done, but it can, and it's not even hard.

Re: 20 years of Git

#212

Post by binarno_sp »

cpeterso wrote: post #123
cjbillington wrote: post #111

Earlier quoted context omitted.

Huh, that's not my recollection. Mercurial on windows was "download tortoisehg, use it", whereas git didn't have a good GUI and was full of footguns about line endings and case-insensitivity of branch names and the like. Nowadays I use sublime merge on Windows and Linux alike and it's fine. Which solves the GUI issue, though the line ending issue is the same as it's always been (it's fine if you remember to just set…

When evaluating successors to CVS back in 2007, Mozilla chose Mercurial because it had better Windows support than git. 18 years later, Mozilla is now migrating from Mercurial to git.

I migrated from Hg to Git a few years back, only because BitBucket forced my hand and most of the hosted CI tools stared dropping support for Mercurial. But I still prefer Hg over Git.

Re: 20 years of Git

#213

Post by BrotherBisquick »

jordigh wrote: post #65

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…

[dead]

Re: 20 years of Git

#214

Post by Digit-Al »

dspillett wrote: post #207
pabs3 wrote: post #196

Earlier quoted context omitted.

Non-source files should indeed never be in the VCS, but source files can still be binary, or large, or both. It depends on how you are editing the source and building the source into non-source files.

Also, some source files that could otherwise be treated as text⁰ end up effectively being binary blobs because tools don't write them in a stable order, which makes tracking small changes difficult because you can't see that they actually are small changes. A number of XML formats¹, and sometimes JSON & others, have this issue too. ---- [0] for the purposes of change tracking and merging [1] Stares aggressively at SS…

OMG! Please don't remind me about trying to source control SSIS. One tiny change cascades into 1000 lines of source being different. Total nightmare.

Re: 20 years of Git

#215

Post by acheron »

Seattle3503 wrote: post #92
WalterBright wrote: post #15

Earlier quoted context omitted.

I had actually done a writeup on it, and thought I had lost it. I found it, dated 2/15/2002: --- Consider that any D app is completely specified by a list of .module files and the tools necessary to compile them. Assign a unique GUID to each unique .module file. Then, an app is specified by a list of .module GUIDs. Each app is also assigned a GUID. On the client's machine is stored a pool of already downloaded .modul…

Interesting. I thought calling a program an "app" came with the smartphone era much later.

People called things like Lotus 1-2-3 “killer apps” in the 1980s.

A reference from 1989:

https://books.google.com/books?id=CbsaONN5y1IC&pg=PP75#v=one...

Re: 20 years of Git

#216

Post by kccqzy »

steveklabnik wrote: post #131
esafak wrote: post #54

Earlier quoted context omitted.

Why?

Not your parent. I never understood the "git cli sucks" thing until I used jj. The thing is, git's great, but it was also grown , over time, and that means that there's some amount of incoherence. Furthermore, it's a leaky abstraction, that is, some commands only make sense if you grok the underlying model. See the perennial complaints about how 'git checkout' does more than one thing. It doesn't. But only if you und…

It's more than that; it's also git's incredibly unfriendly way of naming things.

Take for example the "index" which is actually a useful thing with a bad name. Most tutorials start by explaining that the index is a staging area on which you craft your commit. Then why is it called index and not staging area? Incredibly bad name right there from the get go. If you ask what the word "index" means in computer science, people usually think of indices into an array, or something like a search index that enables faster searching. Git's index doesn't do any of that.

And git's model leaks so much implementation detail that many people mistake these for essential concepts; there are people who would tell you any version control system that doesn't have the "index" is not worth using because they don't allow one to craft beautiful commits. That's patently false as shown by jj and hg. This useful concept with a bad name becomes one amorphous thing that people cannot see past.

Re: 20 years of Git

#217

Post by pmarreck »

XorNot wrote: post #77
pmarreck wrote: post #45

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.

Linux namespaces and Nix closures solve different problems at different stages of the software lifecycle. Namespaces isolate running processes; Nix closures guarantee build-time determinism and reproducibility across systems.

Namespaces don’t track transitive dependencies, guarantee reproducible builds, enable rollback, or let you deploy an exact closure elsewhere. They’re sandboxing tools—not package management or infra-as-code.

If anything, the two are complementary. You can use Nix to build a system with a precise closure, and namespaces to sandbox it further. But calling namespaces a "more complete solution" is like calling syscall filtering a replacement for source control.

Also, minor historical nit: most namespaces existed by the late 2000s; Nix’s whitepaper was written after that. So the premise isn’t even chronologically correct.

Re: 20 years of Git

#218

Post by g-b-r »

eternityforest wrote: post #80
jordigh wrote: post #65

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…

I just wish they'd extend git to have better binary file diffs and moved file tracking. Remembering the real history matters, because preserving history is valuable by itself, but I'm also really glad that VCS is for most people completely solved, there's nothing besides Git you have to pay attention to, you learn it once and use it your whole career.

> but I'm also really glad that VCS is for most people completely solved, there's nothing besides Git you have to pay attention to, you learn it once and use it your whole career.

From what I hear most current new developers never really learn git, they learn a couple features of some git GUI.

And it's understandable, you're really understating what learning git (one of the messiest and worst documented pieces of software ever) well entails.

I find it a disgrace that we're stuck at git, actually.

Re: 20 years of Git

#219

Post by g-b-r »

Izkata wrote: post #164
eternityforest wrote: post #80

Earlier quoted context omitted.

I just wish they'd extend git to have better binary file diffs and moved file tracking. Remembering the real history matters, because preserving history is valuable by itself, but I'm also really glad that VCS is for most people completely solved, there's nothing besides Git you have to pay attention to, you learn it once and use it your whole career.

> I just wish they'd extend git to have better binary file diffs It's not built-in to git itself, but I remember seeing demos where git could be configured to use an external tool to do a visual diff any time git tried to show a diff of image files. > and moved file tracking. Check out -C and -M in the help for git log and blame. Git's move tracking is a bit weirder than others (it reconstructs moves/copies from hist…

It demonstrably can't detect all moves, Torvalds' theory that you didn't need moves tracking was bulls*it.

Re: 20 years of Git

#220

Post by bloopernova »

phire wrote: post #146
jordigh wrote: post #65

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…

I do think an open source, distributed, content addressable VCS was inevitable. Not git itself, but something with similar features/workflows. Nobody was really happy with the VCS situation in 2005. Most people were still using CVS, or something commercial. SVN did exist, it had only just reached version 1.0 in 2004, but your platforms like SourceForge still only offered CVS hosting. SVN was considered to be a more r…

Yeah I think people that complain about git should try running a project with CVS or subversion.

The amazing flexibility of git appears to intimidate a lot of people, and many coders don't seem to build up a good mental model of what is going on. I've run a couple of git tutorials for dev teams, and the main feedback I get is "I had no idea git was so straightforward".

Post reply on HN