I never faced git performance issues when working with code. Guess my repos weren't bit. But when I tried to use git as a versioned database of changes in my pet project, I learned a lot about indexes, compacting, etc. Article covers a lot and is very helpful!
nananana9 1 hours ago [-]
Git is industry standard, because for what it give you it's a remarkably robust and simple program to use. We're all vaguely aware that the internals are complex, but the UX is clean and usable enough that the complexity usually doesn't leak out.
But the day this breaks down and I have to deal with bloom filters, packfiles, maintaining the git garbage collector or rerere cleanup, is the day I switch our codebase to a centralized VCS.
This stuff is cool to learn about; but it's 5 layers removed from anything I want to be thinking about in my day to day work.
thfuran 41 minutes ago [-]
I'm pretty sure git is industry standard almost entirely entirely because GitHub exists. I very much disagree that the UX is clean. The cli is more than a bit of a mess.
stingraycharles 33 minutes ago [-]
> I'm pretty sure git is industry standard almost entirely entirely because GitHub exists.
Nah, I remember that time vividly, Github became a thing about a year or two after it was already very much taking the lead.
GitHub became GitHub because git was the winner. There were alternative hubs that supported bazaar and mercurial and whatnot, but git won because for most people, Linus and the kernel team being behind it was reason enough to trust it.
(and I say this as someone who liked hg more than git)
BerislavLopac 36 minutes ago [-]
Anyone who has ever used Mercurial knows very well what a good versioning tool UX looks like...
miroljub 30 minutes ago [-]
> Anyone who has ever used Mercurial knows very well what a good versioning tool UX looks like...
So true. I used Mercurial back in the day and also used Darcs before it, and it helped me realize that the best versioning tool UX that exists is still the one Git provides.
PS: Also CVS, SVN, Perforce, and Clear Case professionally, and gave a try to Fossil. None of them even close to Git usability-wise.
anitil 3 hours ago [-]
I'm only on to chapter two and already it's explained some plumbing details that I somehow have missed all these years. This is great
normie3000 5 hours ago [-]
> LFS adds its own operational overhead.
Seemingly seconds on every remote-touching command, even on a very small repo.
Hendrikto 1 hours ago [-]
What is worse is that for about half a year or so, I now have to authenticate my ed25519-sk key with my Yubikey thrice (!) when using LFS. On every push.
aa-jv 53 minutes ago [-]
I've always wanted to see a book that describes git for the common man and gives them tons of examples for how to use it to do productive things.
Even for a small office, git can be immensely useful. Entire production line workflows can be implemented with git .. if only folks would learn to use it productively.
Its not just for development. Writers can use it productively. Accountants too.
It always kind of irks me that Git hasn't just been folded into the OS front-end UI by any of the OS vendors .. it'd be so revolutionary to give common folks an easy way to manage the timeline/history of their computer use using git.
awesan 52 seconds ago [-]
The obvious reason is that most file formats used by writers, accountants, etc. are binary files which do not very much benefit from git.
snthpy 6 hours ago [-]
I've been wanting to ask this:
Why isn't
git clone --depth 1 ...
the default?
I would guess that for at least 90% of the repos I clone, I just want to install something. Even for the rest, I might hack on the code but seldom look into the history. If I do then I could do a `git fetch` at that point and save the bandwidth and disk space the rest of the time.
dwattttt 6 hours ago [-]
A question: why is git involved at all in this? You don't want a repository.
skydhash 6 hours ago [-]
This! The default was to have a link to download a tarball of the source. And if the user wanted to contribute (or check the devel version), you would add a link to the vcs.
kingstnap 5 hours ago [-]
Grabbing git repos instead of just tarballs is useful.
A) You can update them, because you can git pull to fetch changes.
B) If you want to apply patches on top, its better to have version control so you can keep track of what you changed, especially useful if you want to rebase.
eddythompson80 5 hours ago [-]
I think gitignore solves a problem that is hard to solve with the traditional tarball approach.
Downloading a tarball and running ./configure or make, editing a config file here or there, etc then running `make install` is the most common flow. Now days I find myself frequently editing the Dockerfile to make it to my liking. With a git repo, the owners of the repo have excluded all the local files, build caches, etc and you can keep pulling to get updates stashing and reapplying your local changes. With tarballs, you have to figure it out all over again. Lose your build cache (language dependent maybe), lose a change you made here or there, etc.
Thanks. That's great! I especially like that it then lazy loads the blobs as you need them.
I was going to ask if there's a way to set that as the default but I guess I'll just set up an alias like I have for most of the subcommands I use daily.
jurakovic 5 hours ago [-]
What if that's only you? Git isn't made only for those who "just want to install something"
6 hours ago [-]
aa-jv 51 minutes ago [-]
Its not the default because that'd be counter-productive to developers who use git with larger repositories, which is how git started life in the first place - your clone depth would be entirely useless for Linux kernel developers, for example, if it were default ..
wadefletch 7 hours ago [-]
ted nyman: #1 most knowledgable college football fan in sf
But the day this breaks down and I have to deal with bloom filters, packfiles, maintaining the git garbage collector or rerere cleanup, is the day I switch our codebase to a centralized VCS.
This stuff is cool to learn about; but it's 5 layers removed from anything I want to be thinking about in my day to day work.
Nah, I remember that time vividly, Github became a thing about a year or two after it was already very much taking the lead.
GitHub became GitHub because git was the winner. There were alternative hubs that supported bazaar and mercurial and whatnot, but git won because for most people, Linus and the kernel team being behind it was reason enough to trust it.
(and I say this as someone who liked hg more than git)
So true. I used Mercurial back in the day and also used Darcs before it, and it helped me realize that the best versioning tool UX that exists is still the one Git provides.
PS: Also CVS, SVN, Perforce, and Clear Case professionally, and gave a try to Fossil. None of them even close to Git usability-wise.
Seemingly seconds on every remote-touching command, even on a very small repo.
Even for a small office, git can be immensely useful. Entire production line workflows can be implemented with git .. if only folks would learn to use it productively.
Its not just for development. Writers can use it productively. Accountants too.
It always kind of irks me that Git hasn't just been folded into the OS front-end UI by any of the OS vendors .. it'd be so revolutionary to give common folks an easy way to manage the timeline/history of their computer use using git.
Why isn't
the default?I would guess that for at least 90% of the repos I clone, I just want to install something. Even for the rest, I might hack on the code but seldom look into the history. If I do then I could do a `git fetch` at that point and save the bandwidth and disk space the rest of the time.
A) You can update them, because you can git pull to fetch changes.
B) If you want to apply patches on top, its better to have version control so you can keep track of what you changed, especially useful if you want to rebase.
Downloading a tarball and running ./configure or make, editing a config file here or there, etc then running `make install` is the most common flow. Now days I find myself frequently editing the Dockerfile to make it to my liking. With a git repo, the owners of the repo have excluded all the local files, build caches, etc and you can keep pulling to get updates stashing and reapplying your local changes. With tarballs, you have to figure it out all over again. Lose your build cache (language dependent maybe), lose a change you made here or there, etc.
https://github.blog/open-source/git/get-up-to-speed-with-par...
https://gitperf.com/chapter-11.html
I was going to ask if there's a way to set that as the default but I guess I'll just set up an alias like I have for most of the subcommands I use daily.
and also git
which makes more sense i guess