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

41–50 of 240 posts

Re: 20 years of Git

#41

Post by WalterBright »

endgame wrote: post #23
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…

Sounds like it's also halfway to a version of Nix designed specifically for D toolchains, too, using GUIDs instead of hashing inputs.

It wasn't designed specifically for D toolchains, that was just an example of what it could do.

Re: 20 years of Git

#42

Post by bananapub »

steveklabnik wrote: post #30
AceJohnny2 wrote: post #28

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…

I'm not an expert on this corner of git, but a guess: trailer keys are not unique, that is Signed-off-by: Alice Signed-off-by: Bob is totally fine, but Change-id: wwyzlyyp Change-id: sopnqzkx is not. I've also heard of issues with people copy/pasting commit messages and including bits of trailers they shouldn't have, I believe.

~I think it's more that not all existing git commands (rebase, am, cherry-pick?) preserve all headers.~

ignore, misread the above

Re: 20 years of Git

#43

Post by rwoerz »

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.

AFAIR keyword substitution of $Id$ included the revision number. That would be the commit hash in Git. For obvious reasons you cannot insert a hash value in content from which that hash value is being computed.

Re: 20 years of Git

#44

Post by steveklabnik »

bananapub wrote: post #42
steveklabnik wrote: post #30

Earlier quoted context omitted.

I'm not an expert on this corner of git, but a guess: trailer keys are not unique, that is Signed-off-by: Alice Signed-off-by: Bob is totally fine, but Change-id: wwyzlyyp Change-id: sopnqzkx is not. I've also heard of issues with people copy/pasting commit messages and including bits of trailers they shouldn't have, I believe.

~I think it's more that not all existing git commands (rebase, am, cherry-pick?) preserve all headers.~ ignore, misread the above

That's a downside of using headers, not a reason for using them. If upstream git changes to help this, it would involve having those preserve the headers. (though cherry-pick has good arguments of preserving vs generating a new one)

Re: 20 years of Git

#45

Post by pmarreck »

WalterBright wrote: post #39
pmarreck wrote: post #35

Earlier quoted context omitted.

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!

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)

Re: 20 years of Git

#46

Post by qntmfred »

I think the git usage patterns we've developed and grown accustomed to are proving inadequate for AI-first development. Maybe under the hood it will still be git, but the DX needs a huge revamp.

Re: 20 years of Git

#47

Post by bananapub »

steveklabnik wrote: post #44
bananapub wrote: post #42

Earlier quoted context omitted.

~I think it's more that not all existing git commands (rebase, am, cherry-pick?) preserve all headers.~ ignore, misread the above

That's a downside of using headers, not a reason for using them. If upstream git changes to help this, it would involve having those preserve the headers. (though cherry-pick has good arguments of preserving vs generating a new one)

ah, I'm sorry, I misread your comment (and should have mentioned the cherry-pick thing anyway).

Re: 20 years of Git

#48

Post by eterm »

szvsw wrote: post #29

As someone who wrote my first line of code in approx 2010 and used git & GH for the first time in… 2013? it kind of amazes me to remember that Git is only 20 years old. GitHub for instance doesn’t seem surprising to me that is I’ve never used other source control options besides git, and I sometimes wonder if I ever will!

What surprises me more is how young Subversion is in comparison to git, it's barely older.

I guess I started software dev at a magic moment pre-git but after SVN was basically everywhere, but it felt even more like it had been around forever vs the upstart git.

Re: 20 years of Git

#49

Post by schacon »

palata wrote: post #10

> 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.

Re: 20 years of Git

#50

Post by schacon »

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.

You can probably setup smudge and clean filters in Git to do keyword expansion in a CVS-like way.
Post reply on HN