ethomson

I'm not talking about the fancy tools. I'm talking about just serving Git repositories, not about web applications.

GitHub is distributing your Git repository across multiple servers in multiple racks in real time for reliability and availability and is the world's largest Git repository hosting provider. Some nice conference talks discuss this, like from Git Merge: https://www.youtube.com/watch?v=f7ecUqHxD7o and GitHub Universe: https://www.youtube.com/watch?v=DY0yNRNkYb0

Visual Studio Team Services is hosting your Git repository across Azure, and is hosting the world's largest Git repositories. https://arstechnica.co.uk/information-technology/2017/02/mic...

I have my own Git server as well, and I agree that its maintenance isn't very demanding. But I'm not putting production bits on it. My open source repositories go to GitHub and my private repositories go to VSTS - they're providing a level of service that I simply can't match by myself.

On the contrary, there's a ton of maintenance, and the hosting providers like GitHub and Microsoft pay teams of people to deal with the infrastructure. (I've worked on both.) This involves not just the physical infrastructure like the servers, though of course there's that, but also maintaining the bits on disk. Your repository will get duplicated across multiple disks on multiple machines, perhaps in different availability zones, and then of course they're backed up to yet another location.

So what companies like GitHub and Microsoft provide is - yes - the fancy tools on top but also teams of professionals ensuring that your repositories are available quickly.

Interesting. I'm sorry to hear that; I actually never used an Onyx but I went from a Cray 2 to a Cray X-MP to a Power Challenge. I was skeptical about Irix and the Challenge, mostly because a bunch of consumer-ish processors seemed like a downgrade, but it turned out to be both fast and rock solid for my workload. That said, I was a consumer, not an administrator, so it's very possible that our admins kept the reliability issues from affecting me.

Yeah, I was a bit surprised reading this, myself. $500k for a Y-MP does seem like a nice price - I assume they were getting a machine that had been previously loaned to someone who was upgrading to something massively multiprocessor.

But it seems like the SGI Challenge architecture makes more sense in 1995. An Onyx would be half the price of that Y-MP, with superior graphics. A Power Challenge GR would as performant as the Y-MP, again with superior graphics, though I suspect about the same price. And anything from SGI has better OS and development tools than UNICOS did at the time. Plus they're easier to install, power and cool.

I suspect that moving over to Win32 probably conferred a lot of advantages, developing on the same system that is your target market. I wonder if they would have ultimately done that even if the Cray deal was on the table.

Indeed, you can. What you cannot do, however, is remain alive to get the results.

I'm really pleased to see that this actually outputs plain text results in _plain text_. For example, if I enter `Integrate[Sin[x], x]`, the result is `-Cos[x]` _in text_.

Real, honest to god, copy and pasteable text!

This is at odds with Wolfram Alpha and integrals.com (from its inception to its current integration with Wolfram Alpha) which returns you... a gif. Of Mathematica-rendered text. Ugh.

For Visual Studio Online and TFS, Microsoft is using libgit2 and some custom ASP.NET code for the upload-pack / receive-pack endpoints, stuffing the data into SQL Azure. No filesystem, no `git` executable.

Yes, this is exactly it. Calling git as a separate process clears up the cost of libgit2. And not just one copy of the library, since there are so many users of git within Visual Studio (Team Explorer, GitHub, CodeLens...) there are at least two copies of the library being loaded. (GitHub ships a newer version of libgit2 in VS prior to 15, intentionally. The Microsoft teams should use a single version, the one included with Team Explorer, but communication is hard.)

By dropping libgit2, they freed up some memory. Obviously the overall memory usage of VS and `git` is probably _increased_ but VS teams are flogged until memory usage decreases because nobody will prioritize making it a 64 bit app. (Opposite, in fact: https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-stu...)

There's also the issue that Microsoft hired the maintainer of Git for Windows and lost a maintainer of libgit2.

It's not an ideal situation for libgit2, we certainly liked our relationship with the VS team, but we understand and sympathize with their decision.

John Dvorak may or may not be a notorious troll, and he may or may not be as reliable as a broken clock. But there's one thing that I can say for sure, and it's that John Dvorak isn't the author of this article.

I'm sorry if I misunderstand you, but your comment quite suggests that it has _not_ gotten any press if the takeaway is to switch oils.

Are you suggesting that you still see evidence of people responding to the misinformation reported in this article? And that the news is still reporting this as fact?

When I was in high school, I had a part time job/internship doing QA and writing some software. I was recruited there by my friend, who was blind, a programmer, and also in high school.

He was a great programmer, and very adept at using his screen reader. As far as I know, it only ever gave him one serious complication: since he was a minor, it was set to safe-for-work mode, and it read his coworker's name, a Mr Livshits, as Livsugars.

Hmm. This looks like it deals with UNC paths. I think the parent is asking about what are sometimes called "Win32 file namespace paths" - or at least defined as such by the MSDN article that is canonical https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

These are sometimes erroneously called UNC paths because, well, they _look_ like UNC paths. But UNC paths are used to refer to a path on another host. (In fact, you can specify UNC paths using the Win32 file namespace using the `\\?\UNC\server\resource` mechanism.)

It looks like win_unc will help with UNC, but it looks from a quick glance that it will not help with `\\?\` paths.

Indeed it does. You could talk about Windows the entire operating system, or you could talk about Windows as Win32, but either way - yes - they both have 260 character path length limits _by default_.

I realize that you're saying that Win32 doesn't have a hard limit of MAX_PATH since you can use Win32 file namespace paths (the `\\?\` prefix) to specify long paths. And yes, that's technically correct, you can. But realistically, unless you carefully control the paths that you're writing and no other program is using them, you're pretty much shooting yourself in the foot by trying to do that.

This is because most apps simply use the Win32 APIs with normal paths and not Win32 file namespace paths. So sure - you can write a file that has a name that's 1024 characters, or a file named `CON`, or a file named `hello?`, but only other programs that wisely use `\\?\` paths can do anything with that. Which is basically nothing except the program you just wrote.

It certainly doesn't include almost anything that Windows itself put down during installation. `cmd`, the Windows Shell, the whole of the CLR? None of these can read the file you just wrote.

So the title seems quite accurate to me.

My favorite: "In 2038 I will be either too dead or too rich to care about this"

https://github.com/libgit2/libgit2/blob/7adca53ed65380266309...

Those are unrelated concerns. Microsoft isn't a big homogenous unit. The business unit that would join the Linux Foundation would be Cloud & Enterprise (which does crazy things like open sourcing .NET and joining the Eclipse Foundation).

The business unit that would open source Windows is Windows Development Group, who are mostly stuck in neutral. They can barely perform builds of Windows themselves, it's so huge and tangled and poorly organized. They can't change anything because they're crippled with decades of technical debt. Whether they want to or not (and I don't think that they really do want to) to try to open source that monstrosity is quite far away.

That said, I'm sure some people within Netscape said the same thing about Mozilla. So I'd love to be proven wrong.

I can't tell if you're joking or serious. Certainly, Microsoft hosts a lot of Linux VMs in Azure. A lot. The last I heard, Azure was hosting more Ubuntu than anything else.

I'm going to assume you're serious and agree with you; I wouldn't be at all surprised if Microsoft did end up joining the Linux Foundation. I'll guess within the next 2 years.

Interesting. I was part of the original "Team Explorer Everywhere" team that built their Eclipse plug-in for TFS and had originally championed this as a good idea. But really, I'm not sure that I'm enthused about this news. Certainly this is good community building, but I've found the Eclipse Foundation to be so ineffective that I'm not sure what purpose this actually serves except to send out a press release.

My team was initially acquired; we were originally a small company in a cornfield in Illinois called Teamprise, where we built the original TFS plug-in for Eclipse. At the time, we were Eclipse Foundation members and reasonably happy about it. Certainly it was nice to give back (in terms of membership fees) to a project that we were a part of and took advantage of. And the Foundation has a few really solid employees and it was nice to talk to them about tech stuff.

But our larger goal in joining the Eclipse Foundation was largely unmet, which was to actually partner. For example: we hoped to bring in a contractor who could occasionally tackle some bugs in Eclipse on AIX which ultimately affected our customers. We were a tiny company and going deep on some weird problem that only affected the Motif AIX build was not particularly rewarding. So we hoped to engage the Foundation to help us out here: we would pay this contractor if they could help us find them. But we were rebuffed in a manner that I found rather off-putting.

Despite this, after we became part of Microsoft I still pushed for us to join the Eclipse Foundation. I stopped pushing when Microsoft had a booth at Eclipse Con one year and a member of the Foundation (apropos nothing) went on a nice, long rant about Microsoft. I don't think it's particularly classy to make fun of your competitors, nor do I really appreciate inculcating an "us vs them" mentality. But to do that after we had paid a big hunk of money to sponsor that conference seemed particularly poor form, and if the Foundation is going to make fun of the people who are paying to sponsor their Conference, what does membership buy you? A steaming pile on your doorstep once a year?

In any case, that was when I stopped advocating for Microsoft to join the Eclipse Foundation and instead advocated for us to ignore them wholesale. I hope that my old team has better luck working with them than I did.

Indeed I did read it - my question wasn't "did you move" but "to whom did you move".

This is very helpful information. Can you say if you've moved to a different provider or if you're now racking your own machines? And if you do have a new provider, can you say who you are and how you evaluated them?

I have been doing some research in my (limited) spare time to try to find a new provider, but I still have not made the switch from Linode.

I agree, I'm happy to see more research here. For my uses, a filter based approach makes the most sense, though I can understand wanting a more holistic solution.

My needs are such that I might only want to encrypt a few files, and filters do an adequate job here. But I can understand a limitation where all objects must be encrypted, and thus filter perf is not appropriate.

Filters also have the limitation of leaking the commit and tree information, which may also be sensitive data on some projects.

This is an interesting strategy, and I'm glad to see more research done here, regardless.

Not everybody who uses a code hosting provider like GitHub or Microsoft Visual Studio Team Services uses SSH. Some people use HTTPS for whatever reason (outbound corporate firewalls and proxies, ease of setup, familiarity, or just personal preference). And I would recommend that those users further use two-factor authentication.

This tools is meant to help those users.

Edit: SSH is coming soon.

These are (roughly) orthogonal issues: regardless of whether we support SSH or not, we are going to support HTTPS access to Git repositories. And if we support HTTPS, we must support two-factor authentication. A lot of organizations require this. (In fact, Microsoft itself requires this internally: our authentication to any internal web site uses 2FA.)

So Visual Studio Team Services must support HTTPS with two-factor authentication. This is awfully painful to use git core on the command-line without a credential manager to assist you.

As has been mentioned (repeatedly) this obviously has no use for people using SSH. Indeed, the goal of this tool is explicitly to be helpful for cloud-hosted repositories in Visual Studio Team Services (formerly Visual Studio Online). This is helpful for teams that enforce two-factor authentication over HTTPS. The article assumes a bit of knowledge about this, but does indeed mention this:

> We ported this tool to Mac and Linux to simplify their authentication to remote Git repositories, in particular those hosted in Visual Studio Team Services (VSTS).

Monaco was not an acquisition. Microsoft hired Erich Gamma, who built a team in Switzerland to develop Monaco (and later Visual Studio Code).

Visual Studio Code is not a fork of Visual Studio Online. Visual Studio Online (now Visual Studio Team Services) is not a text editor, it's an ALM system.

It's not about checking out, though. git-lfs aims to avoid the unnecessary transfer and storage of large files.

If you didn't want large files in the work tree, you would use sparse checkout. These are orthogonal problems.

git-lfs (and similar systems) split up the storage of objects into the regular git object store (for small files) and the large file storage. This allows you to configure how you get and push large files independently of how you get and push regular objects.

A shallow clone gives you some `n` commits of history (and the objects that they point to). Using LFS allows you to have some `m` commits worth of large files.

If you want a completely distributed workflow, and have infinite local storage and infinite bandwidth, you can fetch all the large files when you do a normal `git fetch`. However, most people don't, so you can tweak this to get only parts of the local file history that you're interested in.

Indeed this is a trade off that requires some centralization, but so does your proposed solution of a shallow clone. This adds some subtlety and configurability around that.

This _may_ have been the default, knee-jerk guidance for the Windows team, or part of it, but it was certainly not true for the whole of Microsoft, even back in 2010. In 2010, Microsoft was shipping a handful of cross-platform tools that we built and tested on Unix platforms including Mac and Linux, where it's literally impossible to avoid using GPL software.

Today, Microsoft ships even more cross-platform tools (Visual Studio Code) where again, it's required to use GPL tools, and we contribute to others. (I hack on GPL code as part of my job at Microsoft.)

Now, of course, you're right that this was much harder within Microsoft five years ago. And one's risk exposure is different depending on the product portfolio you own (with something like Windows being less risk averse than something like Microsoft Bob). But some very key lawyers with their heads screwed on straight have overhauled our system and it's much, much easier to deal with OSS than it was five years ago. But even then it was certainly _possible_ and actively happening in parts of the company.

If you found that piece of documentation deficient while implementing a packfile parser, then it would be nice to update it to include those details that were lacking to help the next person to reimplement git.

I migrated my Linode from Xen to KVM yesterday; I had a ticket open and needed to migrate my VM to a different host anyway, so I decided to simply migrate to KVM.

After shutting down my VM and clicking "migrate", the migration actually failed, which was a bit terrifying for a few minutes. I was definitely worried that my disk image went poof and that I'd have to restore from a recent backup. Thankfully, Linode's support was there to kick whatever failed and the migration worked after all.

My VM feels a bit more responsive on interactive session, though I haven't benchmarked anything. (I don't really need to, I only serve a few low-traffic static web sites.)

From my (admittedly brief) glance at the documentation, this seems like the opposite of direnv. direnv would allow you to set up configuration values on a per-directory basis, by adding a file in the directory in question. git supports this already, you can simply change the config for the repository in question. The goal of this package appears to automate this so that one doesn't need to reconfigure each individual folder.