News Museum criticizes Microsoft for 'mutilated' MS-DOS 4 open source release — posting on 'stupid' git blamed for the buggy blunder

[Admin]

A museum contends that MS-DOS 4 suffers from "git mutilation" due to being improperly open-sourced.

Museum criticizes Microsoft for 'mutilated' MS-DOS 4 open source release — posting on 'stupid' git blamed for the buggy blunder : Read more

 

[CmdrShepard]

By saying the Git is idiotic this guy tells me all I need to know about him.

In other words, he is dumb as a rock and so is everyone who repeated what he said verbatim.

Neither of the two issues he blamed on Git are Git's fault -- they are fault of the committer.

This article parroting his ignorance in the title is why we still have so many developers not using Git but instead putting source code in RAR archives, leaving commented out code in source files, and keeping change history in comments (or if we are lucky in a file called history.txt).

 

[RichardtST]

Personally, I can't stand Git either. Not for the reasons mentioned in the article, but because they change syntax so often that the documentation simply never matches and one spends hours trying to find something up to date that actually works and doesn't muck things up even worse than it was. Honestly I've never wasted so much time on a source control system before... And the new personal access tokens... OMG. Really? MS succeeding in making something even more useless than it already was. I will be happy when Git fades away into oblivion where it belongs...

As for the archive. It simply cannot be that big. Just zip it up, post it, and call it a day. Why do people overkill these things?

 

[FoxtrotMichael-1]

Personally, I can't stand Git either. Not for the reasons mentioned in the article, but because they change syntax so often that the documentation simply never matches and one spends hours trying to find something up to date that actually works and doesn't muck things up even worse than it was. Honestly I've never wasted so much time on a source control system before...

Ive used git professionally for over a decade. I make multiple commits, PRs, and even sometimes rebases per day. Never once, in that entire time, have I come across a cli command that changed from the last time I used it or a cli command that didn’t match the documentation. It just doesn’t happen, so I have no idea what you’re talking about here. The git hate really boggles my mind. It’s an incredibly powerful SCM that’s actually fairly easy to understand and use if you take the time to learn it.

 

[toffty]

Ive used git professionally for over a decade. I make multiple commits, PRs, and even sometimes rebases per day. Never once, in that entire time, have I come across a cli command that changed from the last time I used it or a cli command that didn’t match the documentation. It just doesn’t happen, so I have no idea what you’re talking about here. The git hate really boggles my mind. It’s an incredibly powerful SCM that’s actually fairly easy to understand and use if you take the time to learn it.

Qft. I've used other tools in my career and Git, hands down, is the best. Is it straightforward? Outside of normal use, no, but Google and SO have the answer.

As for formatting, i'd say zip it up and have the zip exist side-by-side with the formatted version.

Not sure why people lose their heads over this stuff too...

 

[TJ Hooker]

Personally, I can't stand Git either. Not for the reasons mentioned in the article, but because they change syntax so often that the documentation simply never matches and one spends hours trying to find something up to date that actually works and doesn't muck things up even worse than it was. Honestly I've never wasted so much time on a source control system before... And the new personal access tokens... OMG. Really? MS succeeding in making something even more useless than it already was. I will be happy when Git fades away into oblivion where it belongs...

As for the archive. It simply cannot be that big. Just zip it up, post it, and call it a day. Why do people overkill these things?

It sounds like you're maybe confusing github (an MS product) with git (the open source software)? Github has its own, additional CLI that's different than the native git CLI. MS isnt the maintainer of git, I'm not sure if they're even major contributors.

 

[NinoPino]

By saying the Git is idiotic this guy tells me all I need to know about him.

He said that is a nonsense to use git for historical software, not to use git in general.
This is obviously because there is no need to modify anything so no need for a versioning system that, if used improperly, can change original files in sneaky ways.

In other words, he is dumb as a rock and so is everyone who repeated what he said verbatim.

Neither of the two issues he blamed on Git are Git's fault -- they are fault of the committer.

This article parroting his ignorance in the title is why we still have so many developers not using Git but instead putting source code in RAR archives, leaving commented out code in source files, and keeping change history in comments (or if we are lucky in a file called history.txt).

Personally, in case of historical software, I totally agree with Michal Necasek.
There is no need to use complex tools like git because there isn't a single advantage in using it versus standard archives (like zip for example). Archives are more simple, fast, secure and compatible.

 

[CmdrShepard]

He said that is a nonsense to use git for historical software, not to use git in general.

Here's a quote directly from his blog post:

But please please don’t mutilate historic source code by shoving it into (stupid) git.

Emphasis mine.

He rambles on about how bad Git is:

First of all, git does not preserve timestamps, which causes irreversible damage.

While it is true that git doesn't restore them, you can use git-restore-mtime command to work around that with some limitations.

As for why it doesn't restore file times (even though it preserves them in the log) here's a simple explanation:

It's because it would break every build system like make, maven, gradle, etc. that depends on file modification times to know what needs to be rebuilt. If a git checkout or a git pull pulls in commits that are older than the last executable you built, it would give those files an older timestamp. make therefore won't detect them as an updated dependency, and won't include those in a new build without doing a make clean first. This is super annoying.

There is git log for finding the last time a file was modified in version control and ls for finding the last time it was modified on your local disk, and it turns out there's good reasons for keeping those separate.

As for the rest:

For practical purposes, old source files are not text files. They are binary files, and must be preserved without modification. It is not OK to take an old source file and convert it to UTF-8.

No, they aren't binary files. They are text files with specific encoding (CP437 most likely) and DOS line endings (CR/LF).

Finally, it wasn't Git who converted those files, at least not automatically.

This is obviously because there is no need to modify anything so no need for a versioning system that, if used improperly, can change original files in sneaky ways.

Git is perfectly capable of not modifying anything -- you can safely store EXE, DLL and all other forms of files in it without having a single issue.

There is no need to use complex tools like git because there isn't a single advantage in using it versus standard archives (like zip for example). Archives are more simple, fast, secure and compatible.

Again, it's not a problem in what was used, but how was used. He is outright wrong.

 

[NinoPino]

Here's a quote directly from his blog post:

Emphasis mine.

He rambles on about how bad Git is:

While it is true that git doesn't restore them, you can use git-restore-mtime command to work around that with some limitations.

As for why it doesn't restore file times (even though it preserves them in the log) here's a simple explanation:

As for the rest:

No, they aren't binary files. They are text files with specific encoding (CP437 most likely) and DOS line endings (CR/LF).

Finally, it wasn't Git who converted those files, at least not automatically.

Git is perfectly capable of not modifying anything -- you can safely store EXE, DLL and all other forms of files in it without having a single issue.

Again, it's not a problem in what was used, but how was used. He is outright wrong.

You continue to decontextualize his words but in this situation I not agree with your conclusion.
Git for certain is capable of manage this type of source files, but I remain of the opinion that it is not the best tool to use when we have to preserve historical files.
Can you give me a single advantage on using Git versus normal archives when you have this type of files ?

 

[snemarch]

I've used Git for more than a decade, and while it's not perfect, it's the best versioning tool I've used for day-to-day development work so far.

But I agree with Michal Necasek – it's a stupid choice **for releasing historical code**. Yes, you could do hacks for timestamp preservation, and you could commit all files as binary... but for a historical release, a compressed archive is simply a better solution.

If you want to do development on a fork of historical code, Git could be a fine choice - you probably wouldn't care about timestamps at that point, and part of the initial work would be ensuring you're able to build and release from the new repo, get tooling fixed, et cetera.

 

[CmdrShepard]

You continue to decontextualize his words

No, I am just quoting what he said and what you seem to be ignoring -- he said "stupid Git".

There's nothing to decontextualize -- saying that the most commonly used distributed version control system which even Microsoft uses to store Windows source code written by none other than Linus Torvalds for the purpose of managing Linux kernel codebase is both rude and unprofessional regardless of the context simply because it isn't true.

Git for certain is capable of manage this type of source files, but I remain of the opinion that it is not the best tool to use when we have to preserve historical files.

We can debate whether it's the right choice until we are blue in the face, but it's Microsoft's choice. Perhaps they plan to add newer versions of MS-DOS into the same repo later on in an attempt to reconstruct the code change history? They wouldn't be able to do that with archives.

Can you give me a single advantage on using Git versus normal archives when you have this type of files ?

What is important is that there are no disadvantages as long as it is used correctly which wasn't the case here.

 

[TerryLaze]

It's just a couple of files that you have to send through a converter and then it compiles fine.

View: https://www.youtube.com/watch?v=X7r76V_gWQ8&ab_channel=FreeDOS

 

[NinoPino]

What is important is that there are no disadvantages as long as it is used correctly which wasn't the case here.

Yes there are disadvantages. Because git is more complex to use than zip. Compatibility because zip is available everywhere. Security because a single zip archive is less prone to attacks that a hosted git repository.
I used zip just as example but you can substitute with every format you like.

It's just a couple of files that you have to send through a converter and then it compiles fine.

View: https://www.youtube.com/watch?v=X7r76V_gWQ8&ab_channel=FreeDOS

In this video he use Linux to uncompress a zip with dos source files and build using freeDOS.
I cannot get the point. 😀

 

[TerryLaze]

In this video he use Linux to uncompress a zip with dos source files and build using freeDOS.
I cannot get the point. 😀

Well, you try streaming from a dos system...
It's just easier to do it on your streaming setup with virtualization.

 

[CmdrShepard]

Yes there are disadvantages.

No there aren't.

Because git is more complex to use than zip.

No it is not.

Compatibility because zip is available everywhere.

Git is available everywhere too -- all you need is a browser and as a matter of fact you can download a ZIP of the source code from a repository hosted on GitHub, GitLab, Gitea, ..., etc.

Security because a single zip archive is less prone to attacks that a hosted git repository.

Now you are being silly. Who is going to attack a hosted git repository and why? Don't answer, it's just silly.

In this video he use Linux to uncompress a zip with dos source files and build using freeDOS.
I cannot get the point. 😀

The point is most likely that some DOS tools that might be needed to build this code can no longer run in regular command prompt on Winodws hence the need for FreeDOS. Other than that, you can run FreeDOS in a VM on Windows too.

 

[NinoPino]

Git is available everywhere too -- all you need is a browser and as a matter of fact you can download a ZIP of the source code from a repository hosted on GitHub, GitLab, Gitea, ..., etc.

You can have unzip in every peace of hardware with a C compiler and few resources, no need for a networking stack.
More easy than this ?
On DOS you have unzip, can you say the same of Git ?
To transfer a zip file you do not need an online service or a browser.

Now you are being silly. Who is going to attack a hosted git repository and why? Don't answer, it's just silly.

Of course in the recent history nobody tried to attack an online git repository and nobody have infected repositories with malicious code.
So I suppose you are right, sorry.

The point is most likely that some DOS tools that might be needed to build this code can no longer run in regular command prompt on Winodws hence the need for FreeDOS. Other than that, you can run FreeDOS in a VM on Windows too.

Please, they can do the same also with Windows, the author simply used linux, this is not the point.
The video was linked by Terry that advocate the use of git, but in the video is used a zip archive instead of git.
So the video prove that someone else think that zip is better that git in this particular case.

 

[CmdrShepard]

You can have unzip in every peace of hardware with a C compiler and few resources, no need for a networking stack.

Provide examples of pieces of hardware without networking stack nowadays. I'll wait.

As for the "why use Git" if only you could somehow visit the repository in question and find out:

https://github.com/microsoft/MS-DOS/

Here's what they give as rationale for publishing in a Git repository:

This repo contains the original source-code and compiled binaries for MS-DOS v1.25 and MS-DOS v2.0, plus the source-code for MS-DOS v4.00 jointly developed by IBM and Microsoft.

The MS-DOS v1.25 and v2.0 files were originally shared at the Computer History Museum on March 25th, 2014 and are being (re)published in this repo to make them easier to find, reference-to in external writing and works, and to allow exploration and experimentation for those interested in early PC Operating Systems.

I mean, it is apparent from the commit history that there were 37 people contributing to this public release. How the hell were they supposed to do that with ZIP archives? How would you reference exact function or line of code in your blog post if it was buried in a ZIP file?

And if they already used Git to work on it, why is it such a big deal for you to click Code > Download ZIP button? It's not like anyone is forcing you to use Git.

I swear people complain about most idiotic things nowadays, so entitled and so easily upset when someone else doing work for free doesn't do it their way.