9 ms·

Git 2.33

179 points by mikevm 5y ago

clubdorothe 5y ago
The success of github/gitlab is built on top of git. Are Github / GitLab contributing (money or code wise) to git?
- zufallsheld 5y ago
  This blog post is from github. They made these changes or git and opensourced them. So yes, they do contribute back.
  - ylyn 5y ago
    > They made these changes No, they're just describing the new features... that does not mean GitHub actually wrote these features.
    - IMTDb 5y ago
      First paragraph of the article: > In a previous blog post, we discussed how GitHub was using a new mode of git repack to implement our repository maintenance jobs. In Git 2.32, many of those patches were released in the open-source Git project It looks like GH needed a better algo for git repack. Implemented a better algo for git repack. And contributed the better algo for git repack to the open source project. You can now use the better algo for git repack yourself without using GH. It's fair to say they made the change
- est31 5y ago
  According to their github profile, 3 of the top 10 contributors to git list github as their employer. https://github.com/git/git/graphs/contributors https://github.com/git/git/graphs/contributors In addition, one lists MS. Not sure if that counts. If you restrict yourself to contributions since Jan 1, 2020, you'll even find 4 "proper" Github employees in the top 10, and the 1 MS employee.
- gitgud 5y ago
  It would be a terrible business decision on their part to NOT to have any influence on git...
- agilob 5y ago
  I'm sure it works both ways. If Github was somethingelseHub, somethingelse would be popular. Git started gaining popularity thanks to great UI and communities on github and gitlab.
  - nbsande 5y ago
    That's not strictly true. I'm sure thst GitHub contributed to the awareness of git among and less technically experienced especially in recent years, but use of version control systems has always been the norm in mid to large codebases and git became popular because it improved greatly on the version control systems that came before it. Another big factor contributing to it's popikaroty was that the Linux kernel (that even when git came out was a pretty big codebase already) also used it to great success. The only real credit that can be given to GitHub in my eyes is that it allows individuals to more easily host remote repos.
    - petepete 5y ago
      GitHub made it easier than ever for people to share and collaborate on code. The options that predated it were pretty awful by comparison. It's no wonder that within a couple of years most OSS projects had moved over. GitHub launched in Feb 2008, Git soared and SVN plummeted. https://trends.google.com/trends/explore?date=all&q=%2Fm%2F05vqwg,%2Fm%2F012ct9,%2Fm%2F08441_,%2Fm%2F015_nz,%2Fm%2F06_rjk https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...
    - astine 5y ago
      Git didn't need GitHub to become popular. Torvald's name being attached to it is what did that. But GitHub is what gave Git the near monopoly on open source version control that it enjoys today. Once it became more convenient to contribute to open source projects by forking projects on GitHub than to self-host, that created a barrier against using any other version control system. Other version control systems would be much more popular if it weren't for GitHub.
- throwawayswede 5y ago
  Github didn't even feel the need to include contributors' names...
Tony647 5y ago
Thank you so much for sharing such a useful information. I will definitely share this with others. https://www.paycheckrecords.win/ https://www.paycheckrecords.win/
IshKebab 5y ago
Is anyone working on better LFS integration with core Git? Somebody mentioned on here a while ago how much of a hack it is and how you could make it way better if it was a core part of Git.
- swiley 5y ago
  IMO: LFS is a hack and you probably shouldn't keep large files in git.
  - tester34 5y ago
    Where I should store large binaries then?
    - swiley 5y ago
      In a binary repo (http/sftp server.) That's literally what LFS does.
      - maccard 5y ago
        So your suggestion is to do what lfs does despite not recommending lfs? How do you keep the versions of the binaries in sync with the source code?
- rkangel 5y ago
  There is some discussion of sparse checkouts and 'cone mode' lower down in the article. Proper support for these is the replacement for LFS. LFS is a hack and a workaround for the fact that git ships the whole thing and requires you to have every copy of every blob from the whole of history. LFS cheats this by storing the big blobs elsewhere and only fetching the ones needed for your checkout. It's a giant pain as everyone knows because you've got two sources of data. Instead lots of work is being done on git to remove the "every copy of every blob" requirement. This is in 2 dimensions - only some specified depth of history, and only some subset of the checkout (LFS only helps with the first). Effectively you still only end up fetching the blobs you need from the server for the checkout you're doing. That gets the same benefit of LFS but all in core git.
chucky 5y ago
I think this should link directly to Git's release notes (e.g. https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/ https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/), or the title should be updated to somehow reflect that this is Github's blog post about the changes, not Git's official announcement. Git is not owned or stewarded by Github, and posts like this reinforce the common and unfortunate image that it is.
- remus 5y ago
  I agree with the principal, but in practice the mailing list post is pretty inscrutable to me (as a casual git user, maybe more experienced users find it more helpful?) On the other hand the github blog post provides a lot of extra context and explanation around the changes which adds a lot of value to me.
  - chucky 5y ago
    I agree, I think changing the title is a better solution than linking to the release notes, but I still think it makes sense to offer extra clarity. The original title of the blog post is "Highlights from Git 2.33" which to me is a bit clearer that this is not release notes or any kind of "official" Git 2.33 announcement but rather someone's highlights about Git 2.33. I have no idea why the original submitter chose to edit the title like this.
    - usr1106 5y ago
      > I have no idea why the original submitter chose to edit the title like that Not only that; editing the title is against HN submission guidelines. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - capableweb 5y ago
    I also agree in principal and agree that the GitHub post with additional context is nice. But I'm wondering if this is rather feedback for the Git team to do better release notes (like the GitHub team here) as GitHub will always be biased with their release notes, so it would be better for everyone is the release note from Git were as well. In this particular release, `send-email` is mentioned in the top in the mailing list as it has a new feature. However, GitHub have zero interest in people to use `send-email` as they are basically a competitor to the `send-email` command. So they simply don't mention it in their release notes. This is of course bad, and I'm not sure why they wouldn't at least try to remain impartial. But this is why we need the release notes of the Git team to be better.
vietjtnguyen 5y ago
Cool to see feedgnuplot (https://github.com/dkogan/feedgnuplot https://github.com/dkogan/feedgnuplot) in the wild here: https://i1.wp.com/user-images.githubusercontent.com/443245/129143094-36ced6dd-e241-4810-a7de-39a2e9597386.png?ssl=1 https://i1.wp.com/user-images.githubusercontent.com/443245/1...
teddyh 5y ago
I guess that the next release of Linux will be announced here on HN by a link to a microsoft.com blog post?
- tester34 5y ago
  I hope it'll be written by Linus Torvalds then
deleted 5y ago
[deleted]
svnpenn 5y ago
What I really want from Git, is to be able to have just a single executable for distribution, like `/bin/git` or `git.exe`. Currently Git is a mishmash of C, Shell (yes really), Python, Perl and who knows what else. I found from my own testing that you can actually make a static native build of the core with a few tweaks, but some big chunks of the project are still in other random languages.
- Already__Taken 5y ago
  git is a beacon of 'do one thing well' and honestly I'm not overly impressed
- makecheck 5y ago
  Actually it is very reasonable to choose the right language for the job, especially for tasks that are not performance-critical. When you are writing and debugging something new, you don’t want it to take forever to get it into a correct state. When you are maintaining things, you want readable code. And in an open-source project, you might attract more maintainers if you have code that is more accessible (e.g. simple things appear as simple as they are because they’re scripts, and people familiar with those languages can help even if they are not C programmers). It is also more likely to work cross-platform. I can imagine a lot of things that would be a very simple few lines of script but a mess to write, debug and read in C code. This is especially true if you could have (say) relied on a robust, debugged Python standard library function that has existed for years but instead had to do all of that yourself in C “because the project should only be using C”?
  - svnpenn 5y ago
    The Git project has had at least one full time paid employee (Junio), for over 10 years. In my mind, it's not acceptable that what I'm asking hasn't been done yet. Also, shell is about the worst possible language you could use for a large project. If you want to see for yourself, look at the code for git-bisect. Global state spread across like 5 random shell scripts.
    - deleted 5y ago
vlovich123 5y ago
Does merge-ort also speedup rebase?
- stolee 5y ago
  Yes! Also cherry-pick and revert. But specifically, the ORT strategy can cache computed renames across multiple commits being rebased, so the performance benefits are even greater for "git rebase".
  - WorldMaker 5y ago
    The highlights here point out that much of that added work specifically for "git rebase" to use caches across merges is still left to do, but it will be an additional benefit presumably in a future version.
tooltower 5y ago
I didn't know about `git commit --fixup`, having used git as a daily driver for over a decade. That's super-helpful for fixing things up pre-merge.
stoicjumbotron 5y ago
Are there any good articles/resources which explain how to incorporate some lesser known yet useful git command in your workflow apart from the usual pull, push, rebase etc?

Git 2.33

179 points by mikevm 5y ago

clubdorothe 5y ago

The success of github/gitlab is built on top of git. Are Github / GitLab contributing (money or code wise) to git?

zufallsheld 5y ago
This blog post is from github. They made these changes or git and opensourced them. So yes, they do contribute back.
- ylyn 5y ago
  > They made these changes No, they're just describing the new features... that does not mean GitHub actually wrote these features.
  - IMTDb 5y ago
    First paragraph of the article: > In a previous blog post, we discussed how GitHub was using a new mode of git repack to implement our repository maintenance jobs. In Git 2.32, many of those patches were released in the open-source Git project It looks like GH needed a better algo for git repack. Implemented a better algo for git repack. And contributed the better algo for git repack to the open source project. You can now use the better algo for git repack yourself without using GH. It's fair to say they made the change
est31 5y ago
According to their github profile, 3 of the top 10 contributors to git list github as their employer. https://github.com/git/git/graphs/contributors https://github.com/git/git/graphs/contributors In addition, one lists MS. Not sure if that counts. If you restrict yourself to contributions since Jan 1, 2020, you'll even find 4 "proper" Github employees in the top 10, and the 1 MS employee.
gitgud 5y ago
It would be a terrible business decision on their part to NOT to have any influence on git...
agilob 5y ago
I'm sure it works both ways. If Github was somethingelseHub, somethingelse would be popular. Git started gaining popularity thanks to great UI and communities on github and gitlab.
- nbsande 5y ago
  That's not strictly true. I'm sure thst GitHub contributed to the awareness of git among and less technically experienced especially in recent years, but use of version control systems has always been the norm in mid to large codebases and git became popular because it improved greatly on the version control systems that came before it. Another big factor contributing to it's popikaroty was that the Linux kernel (that even when git came out was a pretty big codebase already) also used it to great success. The only real credit that can be given to GitHub in my eyes is that it allows individuals to more easily host remote repos.
  - petepete 5y ago
    GitHub made it easier than ever for people to share and collaborate on code. The options that predated it were pretty awful by comparison. It's no wonder that within a couple of years most OSS projects had moved over. GitHub launched in Feb 2008, Git soared and SVN plummeted. https://trends.google.com/trends/explore?date=all&q=%2Fm%2F05vqwg,%2Fm%2F012ct9,%2Fm%2F08441_,%2Fm%2F015_nz,%2Fm%2F06_rjk https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...
  - astine 5y ago
    Git didn't need GitHub to become popular. Torvald's name being attached to it is what did that. But GitHub is what gave Git the near monopoly on open source version control that it enjoys today. Once it became more convenient to contribute to open source projects by forking projects on GitHub than to self-host, that created a barrier against using any other version control system. Other version control systems would be much more popular if it weren't for GitHub.
throwawayswede 5y ago
Github didn't even feel the need to include contributors' names...

Tony647 5y ago

Thank you so much for sharing such a useful information. I will definitely share this with others. https://www.paycheckrecords.win/ https://www.paycheckrecords.win/

IshKebab 5y ago

Is anyone working on better LFS integration with core Git? Somebody mentioned on here a while ago how much of a hack it is and how you could make it way better if it was a core part of Git.

swiley 5y ago
IMO: LFS is a hack and you probably shouldn't keep large files in git.
- tester34 5y ago
  Where I should store large binaries then?
  - swiley 5y ago
    In a binary repo (http/sftp server.) That's literally what LFS does.
    - maccard 5y ago
      So your suggestion is to do what lfs does despite not recommending lfs? How do you keep the versions of the binaries in sync with the source code?
rkangel 5y ago
There is some discussion of sparse checkouts and 'cone mode' lower down in the article. Proper support for these is the replacement for LFS. LFS is a hack and a workaround for the fact that git ships the whole thing and requires you to have every copy of every blob from the whole of history. LFS cheats this by storing the big blobs elsewhere and only fetching the ones needed for your checkout. It's a giant pain as everyone knows because you've got two sources of data. Instead lots of work is being done on git to remove the "every copy of every blob" requirement. This is in 2 dimensions - only some specified depth of history, and only some subset of the checkout (LFS only helps with the first). Effectively you still only end up fetching the blobs you need from the server for the checkout you're doing. That gets the same benefit of LFS but all in core git.

chucky 5y ago

I think this should link directly to Git's release notes (e.g. https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/ https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/), or the title should be updated to somehow reflect that this is Github's blog post about the changes, not Git's official announcement. Git is not owned or stewarded by Github, and posts like this reinforce the common and unfortunate image that it is.

remus 5y ago
I agree with the principal, but in practice the mailing list post is pretty inscrutable to me (as a casual git user, maybe more experienced users find it more helpful?) On the other hand the github blog post provides a lot of extra context and explanation around the changes which adds a lot of value to me.
- chucky 5y ago
  I agree, I think changing the title is a better solution than linking to the release notes, but I still think it makes sense to offer extra clarity. The original title of the blog post is "Highlights from Git 2.33" which to me is a bit clearer that this is not release notes or any kind of "official" Git 2.33 announcement but rather someone's highlights about Git 2.33. I have no idea why the original submitter chose to edit the title like this.
  - usr1106 5y ago
    > I have no idea why the original submitter chose to edit the title like that Not only that; editing the title is against HN submission guidelines. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- capableweb 5y ago
  I also agree in principal and agree that the GitHub post with additional context is nice. But I'm wondering if this is rather feedback for the Git team to do better release notes (like the GitHub team here) as GitHub will always be biased with their release notes, so it would be better for everyone is the release note from Git were as well. In this particular release, `send-email` is mentioned in the top in the mailing list as it has a new feature. However, GitHub have zero interest in people to use `send-email` as they are basically a competitor to the `send-email` command. So they simply don't mention it in their release notes. This is of course bad, and I'm not sure why they wouldn't at least try to remain impartial. But this is why we need the release notes of the Git team to be better.

vietjtnguyen 5y ago

Cool to see feedgnuplot (https://github.com/dkogan/feedgnuplot https://github.com/dkogan/feedgnuplot) in the wild here: https://i1.wp.com/user-images.githubusercontent.com/443245/129143094-36ced6dd-e241-4810-a7de-39a2e9597386.png?ssl=1 https://i1.wp.com/user-images.githubusercontent.com/443245/1...

teddyh 5y ago

I guess that the next release of Linux will be announced here on HN by a link to a microsoft.com blog post?

tester34 5y ago
I hope it'll be written by Linus Torvalds then

deleted 5y ago

[deleted]

svnpenn 5y ago

What I really want from Git, is to be able to have just a single executable for distribution, like `/bin/git` or `git.exe`. Currently Git is a mishmash of C, Shell (yes really), Python, Perl and who knows what else. I found from my own testing that you can actually make a static native build of the core with a few tweaks, but some big chunks of the project are still in other random languages.

Already__Taken 5y ago
git is a beacon of 'do one thing well' and honestly I'm not overly impressed
makecheck 5y ago
Actually it is very reasonable to choose the right language for the job, especially for tasks that are not performance-critical. When you are writing and debugging something new, you don’t want it to take forever to get it into a correct state. When you are maintaining things, you want readable code. And in an open-source project, you might attract more maintainers if you have code that is more accessible (e.g. simple things appear as simple as they are because they’re scripts, and people familiar with those languages can help even if they are not C programmers). It is also more likely to work cross-platform. I can imagine a lot of things that would be a very simple few lines of script but a mess to write, debug and read in C code. This is especially true if you could have (say) relied on a robust, debugged Python standard library function that has existed for years but instead had to do all of that yourself in C “because the project should only be using C”?
- svnpenn 5y ago
  The Git project has had at least one full time paid employee (Junio), for over 10 years. In my mind, it's not acceptable that what I'm asking hasn't been done yet. Also, shell is about the worst possible language you could use for a large project. If you want to see for yourself, look at the code for git-bisect. Global state spread across like 5 random shell scripts.
  - deleted 5y ago

vlovich123 5y ago

Does merge-ort also speedup rebase?

stolee 5y ago
Yes! Also cherry-pick and revert. But specifically, the ORT strategy can cache computed renames across multiple commits being rebased, so the performance benefits are even greater for "git rebase".
- WorldMaker 5y ago
  The highlights here point out that much of that added work specifically for "git rebase" to use caches across merges is still left to do, but it will be an additional benefit presumably in a future version.

tooltower 5y ago

I didn't know about `git commit --fixup`, having used git as a daily driver for over a decade. That's super-helpful for fixing things up pre-merge.

stoicjumbotron 5y ago

Are there any good articles/resources which explain how to incorporate some lesser known yet useful git command in your workflow apart from the usual pull, push, rebase etc?