No, this slide is correct. git diff (without any arguments) shows you what you haven't staged. In other words, the different between the working folder (which here is called "workspace") and the index.
3,773 karma · joined May 31, 2012
https://www.edwardthomson.com/
Maintainer of libgit2. https://libgit2.github.io
[ my public key: https://keybase.io/ethomson; my proof: https://keybase.io/ethomson/sigs/48RVOIuAzrPKWNpOT1zlhLUUiT8VXFtqnuo5MzEds_w ]
We're working on artifact caching between runs now, which I think will also help some of the speed issues that you're referring to.
We really appreciate the feedback; if you do get around to trying it again, I'd love to know more about what we could improve.
Apologies, I hastily mistyped, I meant 500 GB, not 5. (5 GB is about the size of my repository, which is not really so big at all and certainly something git can cope with on its own).
This series of articles should illustrate some of the issues that VFS for Git tries to address. ("GVFS" is now called "VFS for Git".)
https://docs.microsoft.com/en-us/azure/devops/learn/git/tech...
And this is a series of articles from an engineer who's been working on improving perf in large repositories in general, not strictly related to the Windows repository:
https://blogs.msdn.microsoft.com/devops/2018/06/25/superchar...
> Windows codebase has 3.5 million files and its repo is 300GB in size. It is not normal. This is google or MS type of problem and not average git user. MS instead changing workflow decided to create GVFS[2]
I didn't say it was normal. Indeed it's uncommon. I said it wasn't pathological.
So I think that I'm not understanding what you're creating, or where. Can you drop me an email with a screenshot? It's my HN username @microsoft.com. Thanks!
You should be able to recurse submodules in a pipeline. In the visual designer, select "Checkout Submodules" in the pipeline's get sources step. If you use YAML, set "submodules: true" or "submodules: recursive" in the checkout keyword.
You should also be able to specify environment variables (including PATH) with the env keyword. But do reach out and we can get to the bottom of this.
Some of these complaints I would agree with - in particularly, we're not (yet) caching build resources - though we're working on this now. But most of these complaints I was quite surprised to hear; not an experience I would want someone to have or what I see from the majority of our customers. So this is certainly a place where I'll follow up with the author to learn more.
From my perspective, it's been interesting to see how people do. Some people bring all of their builds, of course, but some people split it up so that it's a mix of Azure Pipelines and Travis (or, of course, something else). Some people are bringing one or two platforms over - maybe they had Travis working as their build validation system, but it was doing Linux builds. So adding Windows builds with Azure Pipelines made sense. Or they wanted to do macOS or iOS builds, so they started building on our macOS build agents.
Anyway, I'm happy for Travis and I'm glad to see that they're excited about this acquisition. I can speak from first hand experience that running builds for open source projects takes a lot of resources. So I trust that this will help them make sure that they're in a position to continue helping out the open source projects and communities.
#! is special - and not because of magic(5) - if a file starts with `#!`, exec and friends will treat it special. Anything else will be attempted to be executed as a binary.
Now, one _could_ go and install binfmt_misc and set it up so that files with a jar's magic number will be executed a certain way (`java -jar ...`), but this is neither out of the box nor something that all Unix derivatives do.
Notably, binfmt_misc will also work with extensions instead of magic numbers.
However, Visual Studio subscribers do get licenses for Azure DevOps. If you're a Visual Studio Professional subscriber, then you get a Basic license for Azure DevOps. You get additional benefits if you're a Visual Studio Enterprise subscriber. You can find the details at https://docs.microsoft.com/en-us/visualstudio/subscriptions/...
The name made a lot more sense back in the day when the premier client was actually the Visual Studio IDE. But today, most people interact with Azure DevOps with their browser and too many people think "Visual Studio Team Services" is a web-based IDE.
The name change is bittersweet. We've been "Visual Studio <something>" since the first release of our on-premises product, well over a decade ago. But I'm confident about this next phase of Azure DevOps.
For outages, you can subscribe at https://blogs.msdn.microsoft.com/vsoservice (in the toolbar on the right hand side). We don't send out email notifications without you opting in, nor will we, but we do have some ideas to improve the way we notify people that we're working on.
And as for build agents, we're working on that, especially around the caching. Appreciate all the feedback.
Anyway, I'm not a philosopher. But I don't think that this is simply a "rebranding exercise", and it's been in the works for quite a while; it's not related to GitHub (which, for the record, we have not yet acquired).
We've made a huge engineering effort into the individual components that make up Azure DevOps, and those deserve (in my opinion) to be recognized. So, now "Azure Pipelines" gets to shine on its own.
But we have never said that this was Azure's fault. It wasn't. We've put the blame where it belongs: on us. We're nearly done writing up the root cause analysis and an analysis of our next steps to prevent this from happening in the future.