Highlights from Git 2.38 | Hacker News Reader

Highlights from Git 2.38

github.blog

128 pointstodsacerdoti43 comments

--update-refs is great, resetting dependent branches after rebasing has been a constant source of annoyance

ooh, interesting.

Looks good, but I wonder how my colleagues' local checkouts will respond to "updated refs" when pulling/pushing

I don’t see how it would cause a problem unless you force pushed.

No differently to the previous way of doing stacked PRs? There's no getting around the fact that you're force-pushing a new version of each branch in the stack.

This just automates the previously-manual process of checking out branch2 and rebasing it to point to branch1, instead of pointing to the commit that branch1 referenced pre-rebase.

I usually just `git rebase --onto` any dependent branches. I will have to see if `--update-refs` is more convenient (it should be) and if it works well enough for me.

It seems odd that `scalar` is not a sub-command of `git`. Does anybody know the reason behind this?

On top of that, it reads like scalar is essentially just a different default config profile.

This approach feels... wrong.

it seems like it was made at microsoft, using .net[0]

I agree it seems quite strange that it's not a git subcommand now that it seems like it's been incorporated into the git core release. I'm not exactly sure of it's utility...seems kinda heavy weight to just be setting recommended configurations? I guess it does some background automation for fetching and gc?

[0] https://devblogs.microsoft.com/devops/introducing-scalar/

> I'm not exactly sure of it's utility...seems kinda heavy weight to just be setting recommended configurations?

According to the email linked in your sibling, that's exactly why it's a separate command in /contrib and not integrated into git proper.

Since that original patch, the codebase was moved out of contrib and is now scalar.c alongside the other git source files.

Remaining a seperate command rather than a subcommand is motivated by command line backwards compatibility for users of the c version from microsoft/git, but also for users of the older C# version.

If they did git-scalar then they would still need a contrib subfolder command wrapper executable (not just a script, as many users are on windows and rely on it being an executable, not just a bash script).

This confused me too. The rationale seems to be explained in more detail in https://www.spinics.net/lists/git/msg421817.html

That explains why it was added to git/contrib. It seems to have moved out of contrib with essentially no discussion.

The original commit adding it to contrib anticipated moving parts of it into git proper:

    For example, we previously discussed the idea of a "git big-clone" that does
    much of what "scalar clone" is doing. This patch series is a step to make
    such functionality exist in the Git code base while we simmer on what such a
    "git big-clone" command-line interface would look like.

    This is one of many possible ways to do this. Creating a 'git big-clone'
    could lock Git into backwards compatibility concerns so it is necessary to
    approach such an endeavor with caution.

Seems like now it is locked into backwards compatability concerns around including the scalar command.

Thank you, I had missed that it was moved out of contrib.

--update-refs sounds fantastic, can't wait to try it out - I run into this problem all the time and rebasing multiple branches is such a PITA.

I script around such rebases daily. Even in cronjobs, to keep my forks and patches uptodate. Wonder if the new option is as stable as my scripts.

Anyone have experience with using Scalar? How is it? How far can it scale?

I'm also curious how they managed to drive it into the Git project. Presumably there can't be that many orgs out there for whom git repo size is a bottleneck. My rationale there is that the Linux kernel has thousands of contributors and vanilla Git scales ok there. Maybe I'm being naïve about something?

Some companies use monorepos with over .5 million files and a 6.4 GB working tree size (Twitter, Uber, etc.)

The Scalar feature of git is answered prayer for devs at such companies where an average git status command can take upwards of 30s!

Source: I attended the Git Merge 2022 conference in Chicago, IL last month.

I know there are advantages to monorepos but when I hear such stories I just scratch my head. How did they let things get so bad that this would be the case? Surely the advantages monorepos provide would eventually have been overshadowed by the abysmal performance. It seems like they must have already split the repo, switched to something other than git, or devised custom tooling to handle the pain.

Obviously MS devised such tooling and here we are... but have others just been quietly doing similar internally and never showing it the light of day?

> Presumably there can't be that many orgs out there for whom git repo size is a bottleneck.

There are many large orgs that are using pretty large monorepos. Which surprised me.

Source: see my profile :)

Google evaluated git for use internally and rejected it, partially because it was not able to handle its huge monorepo well.

Other day I started using a remote machine and after some months a git command behaved unexpectedly. I checked git version and it was a very old one. I realized that I'm not using any new feature of git.

What am I missing? Which somewhat newer Git feature or configuration are you using that is useful?

Only thing I know of that's fairly recent that I use is sparse-checkout:

https://www.git-scm.com/docs/git-sparse-checkout

It's another feature that's mainly useful for large repos.

Everything else I use was there a decade or more ago, I think.

ssh key signing and probably some commands like switch...

switch and restore, though still both marked experimental, are often cleaner interfaces to common tasks otherwise buried in branch, checkout, and reset

diff.colorMoved can be quite useful (not sure when it was added)

https://git-scm.com/docs/git-diff#Documentation/git-diff.txt...

3-way conflict visualisation is excellent. It allows you the original parent as well as the current and incoming. Saves so much faff figuring out how to resolve a conflict.

https://medium.com/@karol.rossa/git-3-way-merge-addc2728c300

git range-diff is great for seeing what changed after a rebase. It shows you which commits were added, removed, reordered, and changed (with a diff of course) all with color.

Is Scalar really written in C#, doesn’t run on Linux, and is now part of the git codebase? I’m confused.

Why would you think it doesn't run on Linux, or that it's in C#?

EDIT: Ok, it used to be a .NET application (not any more), but .NET runs fine on Linux.

Yeah, I had searched github for it and saw Microsoft’s C# repo for it.

No, the article just mentions it started as C#.

There should be a centralized/online/connected mode for git where commands are executed on the server and only relevant stuff is downloaded locally.

ssh?

git is decentralized, so I don’t think this should be part of the tool itself.

Imagine how often people mess up their repos and tangle up commits. Now imagine it's your company's remote.

Reply on news.ycombinator.com