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

11–20 of 240 posts

Re: 20 years of Git

#11

Post by steveklabnik »

Zambyte wrote: post #7

Speaking of git front ends, I want to give a shout-out to Jujutsu. I suspect most people here have probably at least heard of it by now, but it has fully replaced my git cli usage for over a year in my day to day work. It feels like the interface that jj provides has made the underlying git data structures feel incredibly clear to me, and easy to manipulate. Once you transition your mental model from working branch w…

GitButler and jj are very friendly with each other, as projects, and are even teaming up with Gerrit to collaborate on the change-id concept, and maybe even have it upstreamed someday: https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...

Re: 20 years of Git

#12

Post by DiggyJohnson »

WalterBright wrote: post #5

Around 2002 or so, I had an idea to tag every part of a project with a unique hash code. With a hash code, one could download the corresponding file. A hash code for the whole project would be a file containing a list of hash codes for the files that make up the project. Hash codes could represent the compiler that builds it, along with the library(s) it links with. I showed it to a couple software entrepreneuers (Wi…

Hey Walter, what would you improve with Git?

Re: 20 years of Git

#13

Post by swsieber »

WalterBright wrote: post #5

Around 2002 or so, I had an idea to tag every part of a project with a unique hash code. With a hash code, one could download the corresponding file. A hash code for the whole project would be a file containing a list of hash codes for the files that make up the project. Hash codes could represent the compiler that builds it, along with the library(s) it links with. I showed it to a couple software entrepreneuers (Wi…

While I get how that's like git, it sounds even closer to unison:

https://softwaremill.com/trying-out-unison-part-1-code-as-ha...

Re: 20 years of Git

#14

Post by esafak »

Zambyte wrote: post #7

Speaking of git front ends, I want to give a shout-out to Jujutsu. I suspect most people here have probably at least heard of it by now, but it has fully replaced my git cli usage for over a year in my day to day work. It feels like the interface that jj provides has made the underlying git data structures feel incredibly clear to me, and easy to manipulate. Once you transition your mental model from working branch w…

How long did it take you to become proficient? I assume your organization uses git and you use jujitsu locally, as a layer on top?

Re: 20 years of Git

#15

Post by WalterBright »

WalterBright wrote: post #5

Around 2002 or so, I had an idea to tag every part of a project with a unique hash code. With a hash code, one could download the corresponding file. A hash code for the whole project would be a file containing a list of hash codes for the files that make up the project. Hash codes could represent the compiler that builds it, along with the library(s) it links with. I showed it to a couple software entrepreneuers (Wi…

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 .module files. When a new app is downloaded, what is actually downloaded is just a GUID. The client sees if that GUID is an already built app in the pool, then he's done. If not, the client requests the manifest for the GUID, a manifest being a list of .module GUIDs. Each GUID in the manifest is checked against the client pool, any that are not found are downloaded and added to the pool.

Once the client has all the .module files for the GUIDs that make up an app, they can all be compiled, linked, and the result cached in the pool.

Thus, if an app is updated, only the changed .module files ever need to get downloaded. This can be taken a step further and a changed .module file can be represented as a diff from a previous .module.

Since .module files are tokenized source, two source files that differ only in comments and whitespace will have identical .module files.

There will be a master pool of .module files on WT's server. When an app is ready to release, it is "checked in" to the master pool by assigning GUIDs to its .module files. This master pool is what is consulted by the client when requesting .module files by GUID.

The D "VM" compiler, linker, engine, etc., can also be identified by GUIDs. This way, if an app is developed with a particular combination of tools, it can specify the GUIDs for them in the manifest. Hence the client will automatically download "VM" updates to get the exact tools needed to duplicate the app exactly.

Re: 20 years of Git

#17

Post by WalterBright »

DiggyJohnson wrote: post #12
WalterBright wrote: post #5

Around 2002 or so, I had an idea to tag every part of a project with a unique hash code. With a hash code, one could download the corresponding file. A hash code for the whole project would be a file containing a list of hash codes for the files that make up the project. Hash codes could represent the compiler that builds it, along with the library(s) it links with. I showed it to a couple software entrepreneuers (Wi…

Hey Walter, what would you improve with Git?

Git hasn't quite taken the step of making the hash the URL you use to download a file, any file, and be assured it is exactly what you thought it was, as the hash of the file must match its URL.

This is currently done in a haphazard way, not particularly organized.

Re: 20 years of Git

#18

Post by steveklabnik »

esafak wrote: post #14
Zambyte wrote: post #7

Speaking of git front ends, I want to give a shout-out to Jujutsu. I suspect most people here have probably at least heard of it by now, but it has fully replaced my git cli usage for over a year in my day to day work. It feels like the interface that jj provides has made the underlying git data structures feel incredibly clear to me, and easy to manipulate. Once you transition your mental model from working branch w…

How long did it take you to become proficient? I assume your organization uses git and you use jujitsu locally, as a layer on top?

(not your parent)

> How long did it take you to become proficient?

As with anything, it varies: I've heard some folks say "a few hours" and I've had friends who have bounced off two or three times before it clicks.

Personally, I did some reading about it, didn't really stick. One Saturday morning I woke up early and decided to give it a real try, and I was mostly good by the end of the day, swore of git entirely a week later.

> I assume the organization uses git and you use jujitsu locally, as a layer on top?

This is basically 100% of usage outside of Google, yeah. The git backend is the only open source one I'm aware of. Eventually that will change...

Re: 20 years of Git

#19

Post by WalterBright »

swsieber wrote: post #13
WalterBright wrote: post #5

Around 2002 or so, I had an idea to tag every part of a project with a unique hash code. With a hash code, one could download the corresponding file. A hash code for the whole project would be a file containing a list of hash codes for the files that make up the project. Hash codes could represent the compiler that builds it, along with the library(s) it links with. I showed it to a couple software entrepreneuers (Wi…

While I get how that's like git, it sounds even closer to unison: https://softwaremill.com/trying-out-unison-part-1-code-as-ha...

20 years later :-)

Re: 20 years of Git

#20

Post by renerick »

esafak wrote: post #14
Zambyte wrote: post #7

Speaking of git front ends, I want to give a shout-out to Jujutsu. I suspect most people here have probably at least heard of it by now, but it has fully replaced my git cli usage for over a year in my day to day work. It feels like the interface that jj provides has made the underlying git data structures feel incredibly clear to me, and easy to manipulate. Once you transition your mental model from working branch w…

How long did it take you to become proficient? I assume your organization uses git and you use jujitsu locally, as a layer on top?

It's really not that long. Once you figure out that

1. jj operates on revisions. Changes to revisions are tracked automatically whenever you run jj CLI

2. revisions are mutable and created before starting working on a change (unlike immutable commits, created after you are done)

3. you are not working on a "working directory" that has to be "commited", you are just editing the latest revision

everything just clicks and feels very natural and gets out of the way. Want to create a new revision, whether it's merge, a new branch, or even insert a revision between some other revisions? That's jj new. Want to move/reorder revisions? That's jj rebase. Want to squash or split revisions? That's jj squash and jj split respectively. A much more user-friendly conflict resolution workflow is a really nice bonus (although, given that jj does rebasing automatically, it's more of a requirement)

One notably different workflow difference, is absence of branches in the git sense and getting used to mainly referring individual revisions, but after understanding things above, such workflow makes perfect sense.

Post reply on HN