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

51–60 of 240 posts

Re: 20 years of Git

#51

Post by aseipp »

AceJohnny2 wrote: post #28
steveklabnik wrote: post #11

Earlier quoted context omitted.

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

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 your commit messages, for any commits you send out. It's not the worst thing in the world and it is a little fiddly bit of code.

But ignore all that: the actual _outcome_ we want is that it is just really nice to run 'jj gerrit send' and not think about anything else, and that you can pull changes back in (TBD) just as easily. I was not ever going to be happy with some solution that was like, "Do some weird git push to a special remote after you fix up all your commits or add some script to do it." That's what people do now, and it's not good enough. People hate that shit and rail at you about it. They will make a million reasons up why they hate it; it doesn't matter though. It should work out of the box and do what you expect. The current design does that now, and moving to use change-id headers will make that functionality more seamless for our users, easier to implement for us, and hopefully it will be useful to others, as well.

In the grand scheme it's a small detail, I guess. But small details matter to us.

Re: 20 years of Git

#52

Post by ajross »

fragmede wrote: post #26
frutiger wrote: post #25

Earlier quoted context omitted.

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.

Every git repo has a copy of that mapping instead of there being a central registry though, and because the commit author's name and email, and the date of the commit and a commit message (among other things) go into the hash that represents a commit, it's not that big a difference, is it? 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 if I…

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 delta the file contents itself.

Re: 20 years of Git

#53

Post by schacon »

rwoerz wrote: post #43
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.

You can use smudge and clean filters to expand this into something on disk and then remove it again before the hash computation runs.

However, I don't think you would want to use the SHA, since that's somewhat meaningless to read. You would probably want to expand ID to `git describe SHA` so it's more like `v1.0.1-4-ga691733dc`, so you can see something more similar to a version number.

Re: 20 years of Git

#55

Post by schacon »

alkh wrote: post #3

Thanks for the useful article! In addition to a lot of interesting info, it lead me to this repo containing an intro to git internals[1]. Would highly recommend everyone to take a look [1] https://github.com/pluralsight/git-internals-pdf

Ah yes. It was pretty cool that when Peepcode was acquired, Pluralsight asked me what I wanted to do with my royalties there and was fine with me waiving them and just open-sourcing the content.

It also is a testament to the backwards compatibility of Git that even after 17 years, most of the contents of that book are still relevant.

Re: 20 years of Git

#56

Post by frutiger »

WalterBright wrote: post #34
frutiger wrote: post #25

Earlier quoted context omitted.

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.

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

Re: 20 years of Git

#57

Post by schacon »

jakub_g wrote: post #24

Very interesting to get some historical context! Thanks for sharing Scott. Small remark: > As far as I can tell, this is the first time the phrase “rebase” was used in version control ClearCase (which I had a displeasure to use) has been using the term "rebase" as well. Googling "clearcase rebase before:2005" finds [0] from 1999. (by the way, a ClearCase rebase was literally taking up to half an hour on the codebase…

Good pull. I was wondering if that was a true statement or not. I am curious if Linus knew about that or made it up independently, or if both came from somewhere else. I really don't know.

Re: 20 years of Git

#58

Post by fragmede »

ajross wrote: post #52
fragmede wrote: post #26

Earlier quoted context omitted.

Every git repo has a copy of that mapping instead of there being a central registry though, and because the commit author's name and email, and the date of the commit and a commit message (among other things) go into the hash that represents a commit, it's not that big a difference, is it? 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 if I…

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

Re: 20 years of Git

#60

Post by steveklabnik »

bananapub wrote: post #47
steveklabnik wrote: post #44

Earlier quoted context omitted.

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

It’s all good!
Post reply on HN