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

31–40 of 240 posts

Re: 20 years of Git

#31

Post by jmclnx »

fragmede wrote: post #6
jmclnx wrote: post #4

Yes, still odd, but I can deal with it. FWIW, I just found out you can sign commits using ssh keys. Due to how pinentry + gnupg + git has issues on OpenBSD with commit signing, I just moved to signing via ssh. I had a workaround, but it was a real hack, now no issues! 20 years, wow seems like yesterday I moved my work items from cvs to git. I miss one item in cvs ($Id$), but I learned to do without it.

I don't know if it's lucky or unlucky for you that you managed to skip Subversion

:)

Professionally, I went from nothing to RCS then to CVS then to git.

In all cases I was the one who insisted on using some kind of source code control in the group I worked with.

Not being an admin, I set up RCS on the server, then later found some other group that allowed us to use their CVS instance. Then when M/S bought github the company got religion and purchased a contract for git.

Getting people to use any kind of SC was a nightmare, this was at a fortune 500 company. When I left, a new hire saw the benefit of SC and took over for me :)

In the old days, loosing source happened a lot, I did not what that to happen when I was working at that company.

Re: 20 years of Git

#32

Post by pmarreck »

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…

Can second this. Beware that your old git habits may die hard though. (It's nice that it uses Git as its storage backend, for now, though)

Re: 20 years of Git

#33

Post by pmarreck »

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…

Isn't this basically... a Merkle Tree, the underlying storage architecture of things like git and Nix?

https://en.wikipedia.org/wiki/Merkle_tree

Except that instead of a GUID, it's just a hash of the binary data itself, which ends up being more useful because it is a natural key and doesn't require storing a separate mapping

Re: 20 years of Git

#34

Post by WalterBright »

frutiger wrote: post #25
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…

Your description (including the detailed description in the reply) seems to be missing the crucial difference that git uses - the hash code of the object is not some GUID, it is literally the hash of the content of the object. This makes a big difference as you don't need some central registry that maps the GUID to the object.

There doesn't need to be a single central repository, there can be many partial ones. But if they are merged, they won't collide.

The GUID can certainly be a hash.

Re: 20 years of Git

#35

Post by pmarreck »

WalterBright wrote: post #15
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 .modul…

yeah, allow me to introduce you to the Nix whitepaper, which is essentially this, and thus worth a read for you:

https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf

Another possibly related idea is the language Unison:

https://www.unison-lang.org/

Re: 20 years of Git

#36

Post by WalterBright »

pmarreck wrote: post #33
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…

Isn't this basically... a Merkle Tree, the underlying storage architecture of things like git and Nix? https://en.wikipedia.org/wiki/Merkle_tree Except that instead of a GUID, it's just a hash of the binary data itself, which ends up being more useful because it is a natural key and doesn't require storing a separate mapping

I'd never heard of a Merkle Tree before, thanks for the reference.

Re: 20 years of Git

#37

Post by Zambyte »

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?

I don't really remember exactly how long until I felt particularly comfortable with it. Probably on the order of days? I have never really used any other VCS besides vanilla git before, so I didn't really have any mental model of how different VCSs could be different. The whole working revision vs working branch + staging area was the biggest hurdle for me to overcome, and then it was off to the races.

And yes, I use jj locally with remote git repos.

Re: 20 years of Git

#38

Post by filmgirlcw »

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…

jj is fantastic and I love it so much. Takes the best things I liked about hg but applies it to a version control system people actually use!

Re: 20 years of Git

#39

Post by WalterBright »

pmarreck wrote: post #35
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…

yeah, allow me to introduce you to the Nix whitepaper, which is essentially this, and thus worth a read for you: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf Another possibly related idea is the language Unison: https://www.unison-lang.org/

Thank you. Looks like my idea precedes Nix by 2 years!

Re: 20 years of Git

#40

Post by bananapub »

since it seems it has been forgotten, remember the reason Git was created is that Larry McVoy, who ran BitMover, which had been donating proprietary software licenses for BitKeeper to core kernel devs, got increasingly shirty at people working on tools to make BK interoperate with Free tools, culminating in Tridge showing in an LCA talk that you could telnet to the BK server and it would just spew out the whole history as SCCS files.

Larry shortly told everyone he wasn't going to keep giving BK away for free, so Linus went off for a weekend and wrote a crappy "content manager" called git, on top of which perhaps he thought someone might write a proper VC system.

and here we are.

a side note was someone hacking the BitKeeper-CVS "mirror" (linear-ish approximation of the BK DAG) with probably the cleverest backdoor I'll ever see: https://blog.citp.princeton.edu/2013/10/09/the-linux-backdoo...

see if you can spot the small edit that made this a backdoor:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL;

Post reply on HN