Git 2.38 Adds Microsoft's "Scalar" Repository Management Tool

[phoronix]

Phoronix: Git 2.38 Adds Microsoft's "Scalar" Repository Management Tool

Git 2.38 was released on Sunday and most notable with this feature release is the inclusion of scalar as a Microsoft-developed repository management tool to make it easier dealing with very large Git reposotories...

https://www.phoronix.com/news/Git-2.38-Released

[kpedersen]

Microsoft originally announced Scalar back in 2020 as a .NET Core application for Git. It's since been rewritten in C code

I wonder why they didn't choose C or C++ in the first place? Were they initially not planning on releasing it to the public or did they realize too late that people simply weren't going to install an entire VM platform just to run a part of a version control tool. Rewriting is never a good use of time.

[RahulSundaram]

I wonder why they didn't choose C or C++ in the first place? Were they initially not planning on releasing it to the public or did they realize too late that people simply weren't going to install an entire VM platform just to run a part of a version control tool. Rewriting is never a good use of time.

Looks like they largely wrote it for their own needs originally when they internally moved over to using Git mono repos and in that case, it's probably the case of them writing it in C# because it easier to develop and it fits into their ecosystem well and have recently decided to generalize it more, likely driven by post Github acquisition needs and submitted it upstream to be part of Git which requires it to be C. Rewrites are occasionally a good use of time because among other things, requirements have changed. Hardly an uncommon thing in the industry including in major tech companies and open source projects.

[tildearrow]

Typo......................

Phoronix: Git 2.38 Adds Microsoft's "Scalar" Repository Management Tool

Git 2.38 was released on Sunday and most notable with this feature release is the inclusion of scalar as a Microsoft-developed repository management tool to make it easier dealing with very large Git reposotories...

https://www.phoronix.com/news/Git-2.38-Released

[cl333r]

Looks like they largely wrote it for their own needs originally when they internally moved over to using Git mono repos and in that case, it's probably the case of them writing it in C# because it easier to develop and it fits into their ecosystem well and have recently decided to generalize it more, likely driven by post Github acquisition needs and submitted it upstream to be part of Git which requires it to be C. Rewrites are occasionally a good use of time because among other things, requirements have changed. Hardly an uncommon thing in the industry including in major tech companies and open source projects.

I've been wondering, what is the byte order (endianness) of the ".git" files stored by git? I imagine if I have a copy of a project with the hidden .git folder inside and I copy it to a computer with a different byte order - will it work? By which I mean will git still properly work with the ".git" folder from a PC with different byte order? I don't have a non-LE PC so can't check. Googling "git endianness" couldn't find anything useful.

[RahulSundaram]

I've been wondering, what is the byte order (endianness) of the ".git" files stored by git? I imagine if I have a copy of a project with the hidden .git folder inside and I copy it to a computer with a different byte order - will it work? By which I mean will git still properly work with the ".git" folder from a PC with different byte order? I don't have a non-LE PC so can't check. Googling "git endianness" couldn't find anything useful.

Perhaps this is a good starting point for your research. Tldr: it should work.

[coder]

I've been wondering, what is the byte order (endianness) of the ".git" files stored by git?

If I had to guess, I'd say probably big endian, because that's unfortunately what the industry seems to have settled on (thanks, Sun).

I imagine if I have a copy of a project with the hidden .git folder inside and I copy it to a computer with a different byte order - will it work?

Yes. I don't know this for a fact, but if any modern software should have bi-endian support, it would be git. People still run big endian, on a handful of machines, and they use git.

Thankfully, it's largely a non-issue. I just wish that convention known as "network byte order" hadn't stuck.

[coder]

So, with this merged, I guess the developers can move on to their next project SuperScalar !
🤣 🤣 🤣


...or maybe Vector ? Anyway, it was a bad name unless they were trying to whet our appetite for what's next.

[discordian]

I've been wondering, what is the byte order (endianness) of the ".git" files stored by git? I imagine if I have a copy of a project with the hidden .git folder inside and I copy it to a computer with a different byte order - will it work? By which I mean will git still properly work with the ".git" folder from a PC with different byte order? I don't have a non-LE PC so can't check. Googling "git endianness" couldn't find anything useful.

Most of the .git files are text and gzipped text. The repository is machine independent.

Moving your workspace (the checked out stuff) between windows and Unix will cause a mess with the encoding/line endings however.

Best to only transfer the .git directory

[discordian]

Thankfully, it's largely a non-issue. I just wish that convention known as "network byte order" hadn't stuck.

Wouldn't be an issue if the abhorrent little endian hardware gotten dominant after IBM bean counters picked such a horrible CPU just to piss of generations of engineers