Posted
by
BeauHDon Friday November 17, 2017 @06:10PM
from the up-scale dept.

An anonymous reader writes: One of the more surprising stories of the past year was Microsoft's announcement that it was going to use the Git version control system for Windows development. Microsoft had to modify Git to handle the demands of Windows development but said that it wanted to get these modifications accepted upstream and integrated into the standard Git client. That plan appears to be going well. Yesterday, the company announced that GitHub was adopting its modifications and that the two would be working together to bring suitable clients to macOS and Linux. Microsoft says that, so far, about half of its modifications have been accepted upstream, with upstream Git developers broadly approving of the approach the company has taken to improve the software's scaling. Redmond also says that it has been willing to make changes to its approach to satisfy the demands of upstream Git. The biggest complexity is that Git has a very conservative approach to compatibility, requiring that repositories remain compatible across versions.

Microsoft and GitHub are also working to bring similar capabilities to other platforms, with macOS coming first, and later Linux. The obvious way to do this on both systems is to use FUSE, an infrastructure for building file systems that run in user mode rather than kernel mode (desirable because user-mode development is easier and safer than kernel mode). However, the companies have discovered that FUSE isn't fast enough for this -- a lesson Dropbox also learned when developing a similar capability, Project Infinite. Currently, the companies believe that tapping into a macOS extensibility mechanism called Kauth (or KAuth) will be the best way forward.

It's not hard to put git on a server that users have access to in a small corporate setting that then provides a central location to push to and pull from without needing GitLab to front it. It's nicer with something like that there, but not essential. The main issues with development are still communications and resolving branching for business needs, and merging when the communication regarding changes was insufficient. A nice front end to git doesn't currently fix that.

No, it's not peculiar. Keeping control of a _canonical_ git repository is very useful for a critical security system. It's awkward, but feasible, to link a local, working git repository to multiple upstream repositories such as github, gitlab, or an internal business managed erpository. I've certainly done so and guided technology partners in doing so.

No, it's not peculiar. Keeping control of a _canonical_ git repository is very useful for a critical security system. It's awkward, but feasible, to link a local, working git repository to multiple upstream repositories such as github, gitlab, or an internal business managed erpository. I've certainly done so and guided technology partners in doing so.

You know what's the best tool for that? Gerrit. It's also got a pretty damn nice web interface, and of course, integrates with every CI system out there Let i

Gitolite is one piece of software that lets you "set and forget" a git server that seldom needs maintenance. The only time I've run into problems with it is when the server ran out of memory during a large operation. But that could be prevented by enabling swap.

So, if I understand it right, they've just reinvented the MVFS system pioneered by ClearCase decades ago?

The whole point of git was to have a decentralized repository, so that the repository could be rebuilt from anyone's local repository in the case of failure.

But the larger problem is that if your dependencies aren't properly managed, you end up downloading the whole repository when you build anyway, so the only thing they've accomplished is delaying the build step rather than the clone step.

But the larger problem is that if your dependencies aren't properly managed, you end up downloading the whole repository when you build anyway, so the only thing they've accomplished is delaying the build step rather than the clone step.

Which is generally fine, since you clone the code so you can dive into it - look at it, make changes, etc. If the first build takes longer because you have to grab the repository, I'm OK with that - I usually schedule the build to happen overnight anyways, so whether it fin

No, it isn't generally fine. You can't have a distributed SCM and break the distributed part. Microsoft literally breaks git. I am guessing the half that was accepted upstream was the part that doesn't, and the half that does break it will never be accepted. Make no mistake about it their approach breaks git by design, intentional or otherwise.

First I would have to teach you how distributed SCM works, which is clearly beyond the scope of a Slashdot post. I'll try to summarize. If I fake clone Linus' tree (references only), then his tree subsequently becomes unavailable, then I am dead in the water, as is everyone using my repo as their upstream. That's the opposite of distributed. Sorry for making you look so stupid so quickly. Off you go now...

Yeah, OK. They do this for the same reason they show the desktop way before you can use it. It makes things appear fast so they can say look... clone times on Linux and Windows aren't radically different now, we must be as good! Seriously, you are clueless about all this, so take the clown shoes comment from the ads you pulled it from and shove them in your mouth where they belong.

You don't get my point because you keep saying I said something I didn't. I didn't say it was a massive conspiracy. Never ascribe to malice what can easily be explained as incompetence as they say. Microsoft can't make their system perform well so they are trying to defer the lower performance parts so that it won't be so obvious. If you can't clone the repo then immediately disconnect all network connections and have access to all files then that is called centralized not distributed. Distributing the cen

Again. Not what I said and you know that. I did realize that this will screw over Linux users too though IF their upstream is Windows hosted using their broken system. So again, they didn't say "let's sabotage the Linux code"; they know that can't happen as the git devs are never going to let that happen. They are sacrificing the distributed part of SCM in exchange for distributing the performance hit over time so it isn't so obvious.

Troll?? I noticed the similarly too, though I've not looked into the details.I actually liked ClearCase...first used it when it was an Atria product and then when it was part of the CaseVision suite on SGI platforms. I have yet find anyone else who feels the same though.

I originally thought much as you do, that it was an attempt to bring Git in line with the old centralized server concept, but then I researched it a little more. Git, as it currently stands, is incredibly slow on very large repos. You might argue that the problem is that the repo is too large, but the solution to that problem frequently requires a Tardis.

The "problem" is that git takes a *conserv*ative approach towards compatibility?

So in other words: Microsoft would like to break git's compatibility with non-Windows?

YOU DON'T SAY!

How many times have we go through this exact story again and again?!

You do not deal with Microsoft. You do not talk to them, you do not take anything from them, you do not follow their suggestions, and you do not get in their van!Lest you want to come out once as the skin worn by Microsoft, and once as dog food from the meat grind

Not to be that guy, but 'typo in headline.' "GNU/Linux" is misspelled. (Sorry, I guess it turns out that I AM that guy.) Second... it's Micro$oft, and therefore, the fact that it's a trap kind of goes without saying.

I've heard of people using git for strange purposes (blogging?!) but for a second reading this headline I had the horrific thought that someone was attempting to create a filesystem backed by git.

Fortunately that's not the case, GVFS [github.com] (not that other GVFS [github.com]) provides a git-compatible filesystem abstraction on Windows 10.

Although I'm not a big git fan, I do have to say I'm impressed with Microsoft's recent moves toward open-source and interoperability. If the Linux Subsystem is ever a first-class citizen in the MS ecosystem, I could even see myself using Windows again.

This is what happens when you pick technologies by popularity and groupthink. Git has very real flaws: the worst UI of any source control system I've ever used, inability to deal with large repositories, a confused and overcomplicated operational model, trouble with storing large binaries. You can always spot the people who learned Git as their first VCS: when confronted with these problems, they'll say things like "monorepos are bad" or "the CLI tools were always meant to have 'porcelain' built on top of them, not used directly, so it's fine if they suck" -- they have drunk the koolaid and can't see things any other way or explain real counterexamples to the contrary.

For hobby projects these are academic problems, but if you're working at the scale of a complete operating system then you have to confront Git's weaknesses head-on and fix them. The fact that MS felt it was worth going down this rabbithole just to follow the crowd is sad.

This is what happens when you pick technologies by popularity and groupthink. Git has very real flaws: the worst UI of any source control system I've ever used,

Whoah, whoah, whoah, now wait a sec here. We're talking about a program invented by Linus Torvalds, the creator of a kernel that routinely sits under userlands where a synonym of "feline" prints the contents of files, where a household cleaner (vim) is a text editor, where "more" and "less" do the same thing despite being literal opposites, and where sometimes, but not always, parameter names are case-sensitive (rm -r == rm -R but rm -i != rm -I).

As a predominantly text version control system it doesn't want large binaries under vc that's not it's job. To manage large binaries you can use git-lfs and git can efficiently to the vc and the large binaries can be served via a service optimized for that.

It seems your at-scale is in fact miss use, be kinder to you vc system.

Whenever someone says this, ask them if they are comfortable with the command-line. The answer is always no.

I've used Mercurial from the command line for 5+ years, didn't even cross my mind to use a GUI for it. Git however is completely unusable to me without SourceTree. Git has a horrible UI, especially on the command line.

Whenever someone says this, ask them if they are comfortable with the command-line. The answer is always no.

I've used Mercurial from the command line for 5+ years, didn't even cross my mind to use a GUI for it. Git however is completely unusable to me without SourceTree. Git has a horrible UI, especially on the command line.

How does Mercurial perform on a 300GB repo? Honest question; I've dabbled briefly with Mercurial on small projects (where I found it nice, but slow) but never looked into how it scales.

It's more like, "I read a Mercurial tutorial once and know how to use that."

The point is, you don't really need to do more to be comfortable with Mercurial on the command line. Things make sense there, unlike with Git which bleeds implementation details all over the UI for no good reason.

btw if Git is "completely unusable to you" on the command-line, you are either incompetent or spreading propaganda, and probably the latter. At the worst, Git is a little confusing on the command-line. If it's completely unusable, the problem is you.

Git is always confusing when coming from most other SCM because it's almost nothing like most other SCM. It's biggest strength it's it's biggest hurdle, when you learn it from the outside in like most people (touching only the common porcelain commands) it's very easy to build up misconceptions that you can get away with but will confuse the fuck out of you as you try to expand your knowledge. To be fair to the git book beginner chapters and other tutorials they do attempt to reveal internals along the way

"distributed version control system" does not define git, that's more of a side effect. That's the problem with people who don't get git, evident in the countless comparisons when you google "the difference between git and mercurial" (two good distributed SCMs), they are full of misinformation and comparisons of things that work on top of git like git client UIs and git webserver interfaces.

The XKCD is probably the most accurate description: "it's a beautiful simple use of graph theory which is extremely fl

If you want to get this fixed, I can give some tips. First, note that the same bug is present in "git diff", so it's not just a gitk thing. Next, you can use "git blame" or "git log -p" to find the commit that originally added that bug. (Find the commit that touched those lines--who added this broken feature?) If you can't understand it, e-mail the original author or the git mailing list. If it seems like a useless feature, ask if it can be removed, and mention that it's buggy. If they say yes, submit a pat

Git with submodules solves the _reverse_ problem. One would have to fragment a project into many distinct git repositories, and maintain them each individually with a master project, to allow developers to check out and work on only one small component at a time. To pick out only a small component for local development, one has to pre-separate and activate that one, separate component as a repository and modify the master repository to use submodules.

GitHub still uses ordinary git repositories, and the people using github still have their whole, complete repositories on their own local machines. Quite different from the MicroSoft GVFS.

If MicroSoft really put 270 GB of source code into one git repository, this only demonstrates how little they learned since the days they had to introduce a weird kind of "precompiled headers" in order to deal with their excessive use of one ".h" file that includes everything.

It's not 1995. Microsoft of today is very different of the Microsoft from two decades ago. The presence of Azure alone guarantees that their old business approaches are irrelevant in today's market.

Microsoft has become one of the premiere open source providers. They've released a huge amount of great open source software, from.NET Core to Visual Studio Code to TypeScript and beyond.

Maybe it isn't apparent to people firmly stuck in the past, such as yourself, but Microsoft has leapfrogged many of the traditional open source companies.

People actually like using.NET Core on platforms like Linux and macOS. They like using Visual Studio Code, because it's an excellent cross-platform IDE. They love using TypeScript because it brings sanity to JavaScript.

Yes, Microsoft does embrace and extend open source software. And we're thankful for it! They're providing us some great improvements. That's what open source is all about: allowing a wide variety of contributors to improve the open source software.

As for the Extinguish phase you're fixated on, it's not an issue. They just aren't doing it. They can't really extinguish the projects based on the code they've released under very liberal open source licenses.

Frankly, I've had far better luck with the open source software from Microsoft than I've had with open source software from the traditional open source companies.

For example, software like.NET Core and Visual Studio Code has greatly improved my Linux experience. It has helped make me a more productive programmer. On the other hand there is a lot of software that didn't come from Microsoft, like systemd, GNOME 3, PulseAudio and NetworkManager, that has actually served to ruin my Linux experience in many ways.

I never thought I'd be saying this, but Microsoft really has helped improve my Linux experience, while many traditional Linux supporters have actually made it worse! I encourage Microsoft to embrace and extend open source software. So far I've found their contributions to be excellent.

Yeah, yeah. We've all heard it before. Shut up. Microsoft has a track record stretching over 30 years of being a bunch of assholes and crooks. A few token efforts is nowhere enough to re-establish any kind of credibility. Establishing yourself as a shill and an apologist is pretty quickly done though, so congrats to that.

The Microsoft of the Halloween Documents doesn't exist anymore. If Linux does something well, Microsoft can make money from it selling Azure to run tasks on. If Android does well, Microsoft gets a chunk of every Android device going out there. So, unlike the past, their revenue streams don't depend on just Windows for an OS. For example, MS SQL server runs on Linux... and MS still gets their cut for licensing.

MS is still a corporation, and they are beholden to the bottom line above all, but MS hitching

So Microsoft hasn't changed because they will stop at nothing to make more money any way they can, regardless of it's impact on society or computing? Microsoft hasn't changed. Windows 10 proves that they will get away with whatever they can and leverage ignorance to line their pockets at every opportunity.

If you can't find the information there you are too stupid to understand it anyway. Just as there is no question that Trump is a degenerate sociopath who takes advantage of the weak and ignorant, so to is it well proven throughout the years that Microsoft is the corporate equivalent.

The larger point, which you missed whilst sniffing your farts, is that those who are challenged to provide data to to back their claims but actually have no data will more likely than not often post a link to Google and demand the challenger find the data themselves while simultaneously trying to "blame the victim". You are weak and ignorant, so my guess that you are a Trump supporter is not without merit.

You have that bass ackwards. In the case of well known, thoroughly documented, and literally indisputable fact being advanced weasels like you try to win the argument by claiming that it is my responsibility to do your homework and then shout "I knew you didn't know the answer! " in hopes that they might save face.

From just an information theory perspective, you've demanded that research be done but you haven't actually specified anything more specific than "MicroSoft hasn't changed."

And I impeach that by pointing out that once upon a time their product was a computer language written by hand by Bill and Paul. And now, Bill and Paul are off doing other things, they don't write the code by hand from the datasheet without a computer anymore. Somebody completely different is blindly pounding out code now! So we know tha

I didn't demand research be done. The other idiot wanted me to give him the answers to the test and I told him I wasn't going to play his little game. Do try to keep up. And you might want to learn about information theory before talking about it. This has nothing to do with it.

If you explained your reasons and he wanted a citation, then it would be reasonable to say, "go and research what I said." But that isn't the case; you made a very very very broad statement, which I already impeached above, and he was asking you for data. Your claim had conclusions, but you didn't make any claims as to if there even is data that supports it. If you don't know if data exists that suppor

Right. It's like when someone says "prove to me I will fall if I jump from this cliff" and I refuse to teach them physics. Proof that there is no proof! Clearly anyone who wanted me to believe that would teach me Physics upon demand! You are a truly special form of special, aren't you?

How many people were in your team? Switching from vss to subversion was an amazing improvement. People get on better with git though as its distributed and gives you the chance to rebase to make commit history less noisy and more concise.

Microsoft was a strong mobile player. The problem is that Apple changed the entirety of what people expected in mobile phones, and MS had to pivot to keep up with it. Before the iPhone, the stylus was part of the interface, as well as a physical hardware keyboard. The iPhone set user expectations to a completely different style.

I will give credit to MS for several things. There is nothing out there as scalable as AD for users, computers, and other core organization in a company. The DHCP protocol is al

There are no git performance issues. There are Windows performance issues. In typical Microsoft fashion they aren't going to make their product better, but rather try to get others to behave differently so that they don't have to fix their garbage.