Microsoft Embraces Git For Development Tools

alphadogg writes "Once vehemently opposed to open-source software, Microsoft has warmed to the development model over the years and will now take the unusual step of incorporating an open-source program developed by Linus Torvalds into its own development tools. Microsoft is integrating the widely used Git, a distributed revision control and source code management system, into its Visual Studio IDE and Team Foundation Server, two of the company's main tools for enterprise developers."

Comments

1st step.

[Kenja]

Step 1: Embrace. Step 2: Extend. Step 3: Replace. Step 4: Discontinue.

Re:1st step.

[Anonymous Coward]

LOL. I'm trying to imagine a universe with Torvalds moving Linux into some Microsoft-controlled source control.

Re:1st step.

[smittyoneeach]

The GPL and the Git community are going to break Mr. Softy somewhere around step #2.

Re:1st step.

[Anonymous Coward]

Repeating this tired dumb meme is in the same category as Godwinning.

Re:1st step.

[rubycodez]

oh yes, Microsoft Source Safe can scale upwards to a planet-wide kernel development effort. If I remember from my employer who used it, it only started showing problems at over twelve users......bwhahahahaha!

Re:1st step.

[Anonymous Coward]

VSS != TFS. Might be time to catch up with 5 years ago. And yes TFS can scale.

Re:1st step.

[fisted]

5. Fork.

Re:1st step.

[grcumb]

The GPL and the Git community are going to break Mr. Softy somewhere around step #2.

Yep. First it's Git, then it's Microsoft GCC, then there's the Apache Solution Server and before too long they're selling Aladdin - The Microsoft LAMP Solution.

"New LAMPs for old! New LAMPs for old!"

ducks, runs....

Re:1st step.

[Anonymous Coward]

Not many people uses TFS especially not after VSS. Also, TFS is really hard to set up. SVN on windows is a whole lot easier.

Re:1st step.

[Anonymous Coward]

Uhhh no. TFS can easily run 1k users per server. Try not to look like a retarded neckbeard stuck in 2001 when you reply.

Re:1st step.

[gargleblast]

And yes TFS can scale.

And at US$499 per user Cal, so can its price.

Re:1st step.

[Jackie_Chan_Fan]

Slashdot.org readers hate microsoft no matter what. Its sad really how willfully ignorant zealots can be.

Re:1st step.

[Anonymous Coward]

Good thing those are included with an MSDN subscription then.

Re:1st step.

[binarylarry]

It's a whole new world!

Re:1st step.

[cheesybagel]

Considering Microsoft themselves prefer to use Perforce for Windows development I would venture to guess that TFS doesn't scale all that well in reality.

Re:1st step.

[armanox]

You only are licensed one user per subscription.

Re:1st step.

[GigaplexNZ]

There's nothing stopping Microsoft from modifying their copy of libgit2 as long as they release the source according to the modified GPL license it is covered by. In fact, Microsoft already have upstreamed some modifications.

Re:1st step.

[Anonymous Coward]

No you didn't. Liar.

Try not to look like a retarded neckbeard stuck in 2001 when you reply.

Re:1st step.

[OhANameWhatName]

Slashdot.org readers hate microsoft no matter what. Its sad really how willfully ignorant zealots can be.

That's because Slashdot.org readers have the sad tendency to generalise everything

Re:1st step.

[Anonymous Coward]

If stating the truth makes me a shill, then I guess I'm a shill. Better than being a liar.

Re:1st step.

[Anonymous Coward]

Liar.

Re:1st step.

[Anonymous Coward]

And yes TFS can scale.

For some definitions of scale...

Review: Team Foundation Server

Until a few months or so ago, the policy where I worked was to use Microsoft’s Visual Source Safe (VSS) for source control. Now, granted, VSS does have something of a reputation for corrupting your repository, which is generally considered to be an unforgivable sin for a source control system. That, however, never happened to me, and VSS wasn’t particularly unusable. However, my current employer has started using Microsoft’s newer source control system, Team Foundation Server (TFS), which, I can honestly say is the first source control system to ever make me wish desperately for the sweet release of a corrupted repository

http://blog.motheyes.com/2010/02/review-team-foundation-server/

Re:1st step.

[Anonymous Coward]

That's because Slashdot.org readers have the sad tendency to generalise everything

Not *all* Slashdot.org readers genera...oh, I get it.

Re:1st step.

[dcooper_db9]

You have to read the whole article :-) "In addition to including Git with TFS, Microsoft is also linking Git with its Visual Studio IDE. The company has released a plug-in that will allow users to commit finished code directly to any Git repository. "

Re:1st step.

[exomondo]

The GPL and the Git community are going to break Mr. Softy somewhere around step #2.

Why? This looks pretty much like what Apple does with XCode.

Re:1st step.

[Anonymous Coward]

I don't see that MS has the influence to do that much anymore. Goodbye Microsoft, take your too-little-to-lateness and your lame Surface with you.

Re:1st step.

[Anonymous Coward]

You only are licensed one user per subscription.

Do you think that's news to anybody?

Re:1st step.

[Anonymous Coward]

A company I worked at a few years ago migrated to TFS and with around 30 users it ran dog slow. In addition, by default TFS is set up to work like VSS, meaning that it locks files exclusively for anyone who has a file checked out. This means that you have to wait until someone is done working on an area of the code before you can also work on that area. This is because the files are set to read-only and you can't edit them in Visual Studio until you check them out. Which makes all the developers copy the source code to a different writable directory to get any work done. And, if someone goes on vacation and the files are still checked out, you have to contact an administrator and try to reason with them that they need to unlock the files. Not to mention, unlike git/svn/etc where the source control is completely separate from the IDE, Microsoft's solutions are tightly integrated with it. This means that operations involving TFS lock up the entire IDE and you have to wait before you can edit any code at all. It locks up the interface in a bad way too because it isn't multithreaded, so sometimes Windows will tell you that the application seems locked do you want to kill it or keep waiting if you try to click anywhere on the IDE if it's in the middle of anything related to TFS. Last but not least, if Visual Studio crashes, which it tends to do on occasion, it forces you to start over with whatever you were planning to do in TFS. And, if TFS was in the middle of checking in files for example, it can leave it in a critical state that requires finesse to clean up. Would MS switching to Git fix any of this? Some but not all, because many of the problems are related to Microsoft's VSS-style integration of SCMs. And, also because Microsoft just doesn't "Get It."

Re:1st step.

[Anonymous Coward]

actually TFS is based off of perforce. MS bought the source code to perforce. Now it isn't suppose to be perforce source but perforce inspired what ever that means. IMPO a perforce clone.

Re:1st step.

[Anonymous Coward]

I think microsoft is kinda trying a different approach with open source now.

Step 1: Embrace. Step 2: Fix the shit for the windows side. Step 3: Make the windows side the only side.

Re:1st step.

[mcrbids]

What makes no sense to me is why they'd use *Git* which is almost hostile towards the Windows platform, and not embrace Mercurial which has always been friendly to Windows users, offers capabilities similar to Git, and is designed more for ease of use and data integrity.

Git is all fine and well, but any VCS that includes both "history rebasing" and "garbage collection" as part of its commit history management, in my opinion, violates the very point of a VCS - to keep track of what was done by who, when. I'll pass, thanks, even if I do have a ton of respect for Linus.

So, Microsoft, why Git?

Re:1st step.

[Anonymous Coward]

Umm, no. By default TFS works like Subversion - edit/merge/commit, not lock/edit/unlock. TFS does keep files read-only; you need to tell the server you're changing the file by doing a tfs "edit" operation. But all that's doing is telling the server that "hey, include this file in my next checkin."

You can argue that keeping client state on the server is stupid, and I would not disagree with you, but it's not exclusive locks. If you had to deal with exclusive locks with TFS, somebody deliberately turned on that mode and should be slapped around for being an idiot.

Re:1st step.

[slimjim8094]

Why do you think garbage collection is related to "keeping track of what was done by who, when"? All it does is clean up files that are no longer part of the commit tree; that is, unreachable and "garbage". A way to create such a file is to 'git add' a file (which puts that specific version in the repo, for later commit) and then make another change. Since it's a different file than it was, you have to re-'git add' it, which creates an entirely new object that is referenced by the eventual commit. Hence, the dangling useless object is garbage and should be cleaned up.

People have been complaining about rebasing for a long time, and there's some valid criticism of it, but given the above I'm not convinced your problems with it are properly understood.

Re:1st step.

[phantomfive]

I think it's an indication that git has won the popularity contest over mercurial, for better or worse.

Re:1st step.

[Anonymous Coward]

They garbage collection has nothing to do with git as a version control system, it's basically an implementation detail that helps with performance.

And history rebasing is frankly extremely useful, and only ever used on work that no one else seen (unless you're crazy and want people to hate you). You are only ever going to rebase to clean up stuff in your own repository, so all it does is encourage you to commit more often since it doesn't need to be perfect and organized with pretty commit messages all ready for public consumption. You've gained negative from a VCS point of view if all you've done is discourage Bob from committing early and often just so you can know the exact steps taken by Bob when Bob was working in Bob's repository.

Re:1st step.

[smallfries]

Why do you think that source control should be an audit of what each person did, rather than a view of how the software got to its current state?

Re:1st step.

[styrotech]

oh yes, Microsoft Source Safe can scale upwards to a planet-wide kernel development effort. If I remember from my employer who used it, it only started showing problems at over twelve users......bwhahahahaha!

12 users? That's doing pretty well. Lots of people ran into trouble with way less than that.

VSS must've been one of the worst MS products in history. It was the kind of crap you'd expect Computer Associates to ship.

Re:1st step.

[subreality]

In my opinion git provides better history guarantees than most other VCSes. Everything in a branch's history is completely set in stone by the sha1 sum of that commit. You can rebase your own local work, but once it's pushed to somewhere other people will see your changes, they're nearly permanent - pushing a rebase forces everyone else to rebase onto your new tree; it is not done lightly, and it is not the kind of thing that results in the history of who did what when getting lost without being noticed.

Compare that to Perforce - you can 'p4 obliterate' a file, and its whole history is gone without a trace. Same deal with svn - they don't give you sharp tools, but you can still dump the repo, edit the dump to make some changes, and load it back up. The history disappears completely.

Rebase makes it easier to DO these things, but the sha1 sums guarantee that you can't change history without being noticed. That's a stronger guarantee than most of the centralized systems.

(Note that Mercurial sha1 tracking as well and thus has similar history guarantees; my comments on history integrity aren't a criticism of hg.)

Re:1st step.

[David Gerard]

Microsoft already ships gcc with Interix.

Re:1st step.

[hawkinspeter]

Looks like someone's a bit tetchy today.

Re:1st step.

[BlackPignouf]

Also :
git reflog

If you need "to keep track of what was done by who", you can, even after a wild rebase.

Re:1st step.

[DrXym]

Git isn't hostile to Windows, although it can be quite a clumsy fit.

The biggest issue is all the line ending conversion nonsense. It has settings to cover this but I've never seen it work properly. Project owners need to write their own .gitattributes files to dictate conversion rules for source code otherwise they could find themselves in a lot of hurt dealing with files which are marked modified because different users have different crlf settings.

Other issues would be things like Unicode paths, case sensitive file names, path lengths and so on. Just don't use such things and you should be okay. Git also doesn't like NTLM authenticating proxies so you need to use ntlmaps or similar to work around that restriction.

Anyway the garbage collection is about physical file management and shouldn't affect the change history or anything else about the project. Basically it just gathers up all the commits which may be residing in their own individual files in the .git database folder and concatenates them together into a pack file. It saves disk space at the expense of slower lookups, so the heuristic attempts to pack files which users are unlikely to use often - commits to inactive branches and so on.

Re:1st step.

[DrXym]

Rebase is probably most useful when you have a long lived branch with lots of commits and lots of merges from other branches and you want to squash all that down and make it relative to another branch you're about to merge into. That way you can see exactly what has changed by comparing the two branches and if the merge screws up (e.g. regression bugs), you can back it out really easily.

Re:1st step.

[Builder]

Because in some industries, national government regulations mean that we have to show this.

Re:1st step.

[Anonymous Coward]

And generalisation is bad!

Re:1st step.

[alexgieg]

Yep. First it's Git, then it's Microsoft GCC, then there's the Apache Solution Server and before too long they're selling Aladdin - The Microsoft LAMP Solution.

Call me crazy, but I don't think any of this is impossible. If at some point Microsoft feels fully embracing the Unix world (of which they never really divorced) would be in their best interest, they'd do all of this and more. Sure, they're really, REALLY attached to Windows, but in the end it all boils down to market and business opportunities. The moment the business world, i.e., their mains customers, starts switching en masse to Unix and Unix-like systems, so will they, if not for other reason that survival.

Not that this has any chance of happening while legacy systems are still required everywhere. For the next few years, perhaps decades, they'll stick to their own stuff. But beyond that things might change quite a bit, in quite surprising ways. Including for the worse.

Re:1st step.

[cyber-vandal]

It's a sign of having a long-term memory. Microsoft spent a couple of decades misbehaving terribly, hence why they were prosecuted in both their biggest markets for monopoly abuse. That they are behaving better finally is good, but, like all habitual criminals, it will take a long time to re-earn people's trust.

Re: 1st step.

[Anonymous Coward]

Because its wildly popular with developers.

Re:1st step.

[sproketboy]

It still works the same shitty way with file checkouts and a read only local files. So LAME.

Re:1st step.

[petermgreen]

In my opinion git provides better history guarantees than most other VCSes.

Lets say I have a main repository. With subversion provided I trust those operating the main repository I can easilly answer the following questions

What code was at the head of a given branch in the main repository at a given time.
How did the code at the head of the branches in the main repository change over time.
Who actually placed that code in the main repository (and in doing so took responsibility for it).

To me being able to answer these questions is the essence of "history" in a version control system.

Afaict git has no good system for answering these questions. Reflog can give you this information but afaict it can only be used if you have direct shell access to the main repository and only if the relavent entries haven't been expired from the reflog.

Re:1st step.

[sproketboy]

Exactly. Microsoft won't even eat their own dog food. Garbage like VSTS is for the peons.

Re:1st step.

[foniksonik]

It's a whole new world!

http://youtu.be/MLsdJlfA23E

Re:1st step.

[Anonymous Coward]

>>Umm, no. By default TFS works like Subversion - edit/merge/commit, not lock/edit/unlock. TFS does keep files read-only; you need to tell the server you're changing the file by doing a tfs "edit" operation. But all that's doing is telling the server that "hey, include this file in my next checkin."

Umm.. why is this step necessary? Can't TFS just diff local file against original and see if there are any changes? Completely useless step, just poinless clicking. Unless you can prove that is essentiall and mandatory.

Re:1st step.

[Eskarel]

The review is would be for the 2008 variation(given 2010 wasn't released till later that year. As my companies TFS admin I can tell you that 2010 is a hell of a let better than 2008 and 2012 is better still. Specifically one of the things they changed in 2010 was to put separate project collections out into their own databases(you couldn't do that with 2008) which needless to say allows you to scale a lot better than was the case when that review was written.

That said, if all you want is version countrol, you probably shouldn't use TFS as you'll find it a bloated pig in comparison to most of the competition. That's mostly because TFS isn't just a VCS it's also a bug tracker, sprint planner and automated test/build server. It actually (IMO) does a damned fine job of it. It's also free with any level of MSDN subscription which is pretty well a given if you're using Visual Studio professionally. If you need the features it provides and are using VS it's actually a pretty good product with no significant downsides(a few odd design choices, but what software doesn't).

Re:1st step.

[Eskarel]

Explicit checkouts have their reasons(primarily TFS is built for a market where being able to tell exactly who has a file they've modified but not checked in is a valuable tool), they can be a bit annoying of course, but if you're using the IDE they are mostly invisible to the end user(there are some noteable exceptions of course, if you're referencing libraries that aren't either in nuget or hosted on the server you can be in for some fun times if you forget to check them out when you update them)

Re:1st step.

[Anonymous Coward]

And some people actually like Stalin...

Re:1st step.

[Anonymous Coward]

If I were an auditor I would be extremely happy with git.

Git encourages to commit often to organize your own work. If a developer using git commits 10 times as often as one using a centralized VCS where frequent commits would result in build errors and lots of insignificant noise in the commit history, I don't think an auditor would be interested in seeing that noise while not minding about missing out on the same information from the other developer. Or perhaps a snapshot should be taken of entire filesystems every minute to follow what everyone in the enterprise was doing. The auditors that looked at my code when I worked for a bank were interested in things like signs of fraud in production code (such as hard coded account numbers), procedures and technical measures that safeguard against that and in a record of who is responsible for which code (and they made a point of saying that was primarily for our own benefit, rather than theirs, the place was also required by law to keep backups of software for at least ten years, the information was available without a VCS). With git you can rebase what amounts to a fancy way of saving files into the same significant commits the other developer produced. That is what rebase is for. A rebase doesn't change history, it creates a new one and it is perfectly possible to keep both in separate branches. The new sequence of commits is not a chronological log of what the developer did, it is a presentation of the changes ordered by topic, an end result the developer takes responsibility for. I think that is the part that counts.

If you need a strong audit trail it will be for the released software, not for every experimental branch developers have lying about. Create a central repository for that and set it up to only accept GPG signed fast-forward commits (that blocks rebased branches; the signatures are actually part of a tag object refering to the commit). Git uses content adressable storage for objects, including those representing directories and commits: every object is identified by a SHA1 hash over its contents. Tree objects (representing directories) and commits refer to other objects (including parent commits) by their SHA1 hash. The hash is determined not only by the current commit's content but by the entire network of history leading up to it, and that is what you sign. Change one bit, even in a version from the distant past, and an integrity check on the repository will fail. It's extremely hard to tamper with, if at all doable (even if SHA1 isn't as strong as it used to be I would like to see someone produce two sources with the same hash, fitting in the same system, without introducing build or runtime errors). That results in a fucking strong audit trail, and it's not added on top of the repository, it is an integral part of how it's stored. Needless to say, a rebase won't preserve commit's hashes, a new history results in different ones. Any signatures in the original branch only apply to the original branch, not to the rebase result. In a repository where every commit should be signed you can't rebase in a way that doesn't show up. And as developers all have their own copies of the repository that don't match the original and can't be pushed into it (fast-forward only) it would show almost immediately.

Re:1st step.

[Anonymous Coward]

TFS can't scale as well as git.

Re:1st step.

[sproketboy]

Dude it's retarded. The problem is compounded by the fact that Visual Studio projects reference every file individually so you're always having conflicts with the project file *every time* a dev add new a file. Scales my ass.

Re:1st step.

[godefroi]

I don't understand why we can't all just get along on the line-ending front. If you're a developer, and you're creating tools that can't handle any line-ending style, then you're a fool that shouldn't be allowed to touch a compiler.

If you're still editing source code in Windows' Notepad (the only text editor I know of in Windows that doesn't sanely handle different line-endings), then you deserve what you get.

Re:1st step.

[Anonymous Coward]

Lets say I have a main repository. With subversion provided I trust those operating the main repository I can easilly answer the following questions

What code was at the head of a given branch in the main repository at a given time.
How did the code at the head of the branches in the main repository change over time.
Who actually placed that code in the main repository (and in doing so took responsibility for it).

To me being able to answer these questions is the essence of "history" in a version control system.

Afaict git has no good system for answering these questions. Reflog can give you this information but afaict it can only be used if you have direct shell access to the main repository and only if the relavent entries haven't been expired from the reflog.

Set up the central server which hosts the main repository so that it only accepts 'fast-forward' merges. This is quite simple to do. If you are not familiar with the git jargon, 'fast-forward' merges are those where the history being merged is strictly an extension of the existing history. As with Subversion, provided you trust those operating the main repository not to go in and manually circumvent the controls, you get everything you want. If you like you can also insist that all submitted commits have to be gpg signed as well, making it impossible for a sysadmin to create a seemingly valid but actually corrupt history.

Re:1st step.

[Anonymous Coward]

As a guy who does software configuration management for a living, you might be surprised at the number of companies using TFS.

Biggest SCM packages these days seem to be SVN (probably the single most common) & Git (primarily small / startup types and big companies with distributed dev teams).with ClearCase (big companies with an investment in IBM that they just don't want to move away from), and TFS (windows-only shops). There are others - Perforce, Bitkeeper, Accurev, Mercurial, and yes, even CVS still... but there's a sizable group of people out there making good use of TFS. Visual SourceSafe was an unmitigated abortion, and should have been mercy-killed in its infancy; TFS is actually a pretty solid product, if you're a windows/.net-centric shop.

Re:1st step.

[Anonymous Coward]

Because everybody knows that companies pay Microsoft's list retail price for their products, right?

Also, why do people get so touchy about software prices? Yes, it's an expense. Compared to the $150-250k total cost per year you're spending on the engineer USING that TFS license, it's not even a fucking rounding error. Salary, equipment, benefits, hardware - all of this *dwarfs* the $499 list price for that product. Let's stop pretending that "cost to license" is a huge factor in purchasing decision making.

You acquire the tool that does what you need and allows your very-expensive engineers to be most productive. For some groups of engineers, yes, that means that TFS is the tool you buy.

Re:1st step.

[Anonymous Coward]

Because Git probably is more used than Mercurial. Just as a rough estimate, go to a job site and search "git" vs "mercurial", see which has more hits.

Sampling dice.com:

"git" - 1,194 results;
"mercurial" - 151 results;

Re:1st step.

[Anonymous Coward]

And if I were a doctor, I'd be extremely happy with saturated fats, because they taste so FUCKING delicious when baked into brownies and donuts.

Auditing is a very real concern in some heavily regulated industries, which means some of these capabilities make git a non-starter. Dismissing those concerns because "I like git, so if I were an auditor, I'd be totally cool with these limitations," doesn't mean those concerns cease to exist in the world.

Git is not the one tool to rule them all - it's appropriate in some instances, it's the wrong tool in others.

Re:1st step.

[hairyfeet]

Oh I'm sorry, that was the policy under Bill Gates who actually knew how to run a business. You have to revise the formula when working under Ballmer's management..

Step 1: Embrace, Step 2: "What is Apple doing?" Step 3: Copy badly what Apple did years before, Step 4: Lose billions while failing horribly.

That is a MUCH more accurate of how things work under the current management, especially when you take into account the fact that he has pissed away something like 40 billion plus on failed ventures in the past 6 years. The old EEE strategy may have been assholeish but it didn't leave MSFT in much worse shape than when they started which is the end result of pretty much every play Ballmer does.

On a final note, to all the FOSS zealots who still think MSFT is the threat? Please leave the 90s and join the rest of us in reality, okay? Ballmer can snatch defeat from the jaws of victory and makes Dilbert's PHB look like Steve Jobs, hell if you want to know what his "strategy" is just look at what Apple was doing 3 to 5 years ago and copy that poorly and there ya go! Frankly we have MUCH worse threats than Uncle Fester the bumbling buffoon to worry about, like Apple's walled gardens or Google pretending to be friendly while making devices like the ChromeBook that is as locked down as any cellphone, now THOSE are problems. Worrying about MSFT whose output for the past few years can be summed up as "fail fail fail fail" is kinda pointless, wait until they actually make another product people will buy (if they ever do) because its like you are ignoring the major issues to nitpick against your "old rival" who frankly isn't even up to the task of being anybody's rival ATM.

For MSFT to be a threat to anything you are gonna have to have somebody with an actual vision in the big chair, as it is now all we have is Apple and a badly done ersatz Apple, and nobody wants ersatz.

Re:1st step.

[Anonymous Coward]

Surface is awesome.

Re:1st step.

[Anonymous Coward]

misbehaving terribly

Aaah, double negatives...

Re:1st step.

[PCM2]

What makes no sense to me is why they'd use *Git* which is almost hostile towards the Windows platform, and not embrace Mercurial which has always been friendly to Windows users, offers capabilities similar to Git, and is designed more for ease of use and data integrity.

According to Microsoft, they chose Git because A.) It's the most popular these days, so by targeting that they reach the largest installed base; and B.) Git has not worked well with/on Windows, and they would like to change that.

Re:1st step.

[MajroMax]

Afaict git has no good system for answering these questions. Reflog can give you this information but afaict it can only be used if you have direct shell access to the main repository and only if the relavent entries haven't been expired from the reflog.

Set up a central, "authoritative" git server for a project that rejects all non-fastforward pushes, and you have exactly the same guarantees. In the meantime, local developers who don't need monotonic history can use the full features of git, and the restrictions can also be relaxed if necessary. For example, a dedicated (trusted) project maintainer could be permitted to make non-ff merges, so development-branch history can still be retained in the central repository.

Subversion doesn't break these guarantees, but that's because it's not powerful enough to do so.

Re:1st step.

[Anonymous Coward]

We've got a comedian over here.

Re:1st step.

[Anonymous Coward]

" it's also a bug tracker, sprint planner and automated test/build server."

And it sucks at all of them equally.

"As my companies TFS admin"

The very fact that this is a title is a WTF. There are no Git admins, there are no SVN admins, but there are jobs all the time for TFS admins because it sucks ass and needs an administrator.

Re:1st step.

[Anonymous Coward]

"That's because Slashdot.org readers have the sad tendency to generalise everything"

        Except, Microsoft did do everything they could to earn that hate.

Re:1st step.

[Anonymous Coward]

Because the companies using SVN and git haven't gotten big enough to need one. By the way if your SVN servers are sitting there untouched and without an admin, who is doing your backups?

Re:1st step.

[Anonymous Coward]

Soooo just like everything else that's included in an MSDN subscription?

Re:1st step.

[Anonymous Coward]

Actually TFS is dogfooded by many teams...and large ones at that...

Sincerely,
an Cowardly Anonymous Microsoftie (who actually prefers Mercurial over any other [D]VCS)

Re:1st step.

[raddan]

Microsoft doesn't use Perforce. They use an ancient, crappy fork of Perforce called Source Depot. I had to endure this piece of garbage while I interned at Microsoft. I can only guess that it's institutional momentum-- SD is so bad that I ended up using Subversion locally and then I would periodically sync back to SD when I needed to share my code. Not only does Source Depot lack run-of-the-mill Subversion features like "svn status", when I asked people what the SD equivalent was, a long conversation ensued with other Microsoft developers in which somebody ended up sending me a Powershell script. Gah. Of course, the number 1 thing I missed there was the UNIX shell.

That said, I was pleasantly surprised by the rest of Microsoft's toolchain. Having come from Eclipse (awful), IntelliJ (OK), and Xcode (baffling), Visual Studio was great. Visual Studio is so much better than any other IDE that I've ever used, that I would actually pay full price for it (I get the "Microsoft alum" discount) if I didn't have to use it on Windows. And Microsoft was more than willing to let me write code in F#, which was fantastic. In general, Microsoft takes care of their devs. Having integrated git is just icing on the cake.

Re:1st step.

[cbhacking]

Wrong and wrong. The NTDEV project (now, generally, "Windows") has been using Source Depot (Microsoft's internal Perforce) since well before VSTS existed, and given the size of the existing code base, much less the immense revision history, migrating to another version control scheme is very much a "if it ain't broke..." situation.

However, many other teams within MS, especially those working on newly developed or re-written code, use VSTS/TFS. This is even true for many smaller projects that would be described as "Windows" stuff, so long as they aren't built as part of the nightly builds or included as dependencies of anything that are. TFS is also used for many other things; the NTDEV folks use it for its task management features (although not the bug tracker, which is also a legacy program they apparently didn't want to migrate off of), while many other groups use it for bug tracking as well.

I never heard of anybody using Visual SourceSafe, though. I don't even recall it ever being mentioned. Subversion was more likely.

Re:1st step.

[rubycodez]

yes i did. those are not the MS white paper reccommendations. those servers would be severly IO bottlenecked running TFS without huge disk array (multiple spindles/LUN) and fibre san attached. bottom line, single lone server, 100+ users brings the thing to a crawl

Re:1st step.

[Eskarel]

I am not a "TFS Admin" I administer my companies TFS system. That is to say I installed it, I will upgrade it to the new version, every once in a while I change some permissions in it and I make sure that it gets backed up. I perform this task because I am a developer with an operational background so I both understand what TFS is for and am not am trusted by my previous colleagues not to blow up their infrastructure so they let me have admin access on servers. This takes a percentage of my time which is so small as to be immeasurable. My reference to the fact that I do this was to say "I am not pulling this information out of my ass, I have actually done this and been paid for it(in the sense that I am paid for any other 30 minute activity I might perform in my job over the course of a year)"

I suppose you could have someone at a large enough organisation who does TFS as a full time job, but they'd probably be more of a build manager than an actual TFS admin(TFS is not a VCS it contains a VCS).

Re:1st step.

[Tough Love]

Microsoft doesn't use Perforce. They use an ancient, crappy fork of Perforce called Source Depot.

Is that more crappy than the current crappy thing called Perforce?

Re:1st step.

[subreality]

Reflogs aren't for history; they're just a convenient undo stack for your own use. Examining project history is pretty similar to most other VCSes. Give it a try:

git clone https://github.com/jquery/jquery.git
cd jquery
git log --stat # answers most of the questions you asked above
git show-branch -a # makes sense of merges
git show 6a82f2a # Shows everything that went into a specific commit
git checkout 6a82f2a # Check out that commit so you can explore the tree
gitk # Start GUI history explorer tool

Hashes are globally unique so if you 'git checkout 6a82f2ae63263ed9deaff9d9dcc775a2c0cde343', you are guaranteed to have the exact same tree as I do; and no matter how many weird rebases you've done, 'git log --oneline --shortstat 6a82f2ae63263ed9deaff9d9dcc775a2c0cde343 -n 5' will show the same history as I have:

6a82f2a Make sure that mousing over XUL elements results in no trigger of a mouseleave. Fixes #6013.
  1 file changed, 13 insertions(+), 16 deletions(-)
dd5c263 Make sure that live focus and blur events also bind to the regular events, to handle triggered events. Fixes #6055.
  2 files changed, 17 insertions(+), 2 deletions(-)
467063a When binding a change directly to a file input just passthrough to the normal bind. A temporary fix for #5997, needs more investigation.
  2 files changed, 13 insertions(+)
c1ac9fd Don't inject style elements using innerHTML as they will go away in IE. Fixes #5977.
  2 files changed, 7 insertions(+), 2 deletions(-)
14e1200 Added some tests to test repeated injected of scripts. Was fixed when fixing #5094.
  1 file changed, 4 insertions(+), 5 deletions(-)

Re:1st step.

[DrXym]

Line endings are a problem for every source control system. If all your devs are running Unix or Windows or OS X then it probably doesn't matter. It's when you have a mixed environment it matters. Or when one dev changes the line ending conversions in their main git config because they're working on multiple things. Anyway the solution in git is a gitattributes file where the behaviour is explicitly set per file type but it's still a pain.

Re:1st step.

[ByOhTek]

Seen this meme a lot. Yet to see them successfully manage it in practice.

They've had Mercurial on Codeplex (their "open source"ish code foundry) for years, and integration tools for it with Visual Studios (though the tools are third party). No troubles there.

Visual Studios has had Java available for a long time, though they use a different name. No troubles (from MS) there.

MS screwed up their implementations of HTML/JavaScript, and it's at most caused annoyances for those of us who have to work with it regularly. Still less than some other things (like flash *grumble grumble*).

Re:1st step.

[ByOhTek]

Whitepapers.

Heh. Maybe MS does things different from the groups I'm used to reading whitepapers for (i.e. Oracle), but whitepapers are generally fluff to give to clueless management to convince them of whatever the hell you want to convince them of on your product, without actually saying much of anything.

I've seen that kind of thing before, to get the management to buy more licenses. Anyone making a decision on a whitepaper is a fool. It's a starting point provided by a companies marketeers with a goal of looking factual. In other words, say as little as possible, and err on the safe side with number to prevent false advertising (if your major commercial competition is worse, err on the extremely safe side to get more purchases out of ignorance for sales).

Re:1st step.

[ByOhTek]

Or mercurial. That's, in my experience, simpler still. And like SVN, GIT and unlike TFS (or VSS)... Free as in beer.

Re:1st step.

[Anonymous Coward]

Seems sensible. No point reinventing the wheel if Mercurial is good on windows. Plus, supporting git properly as opposed to other offerings is a selling point.

Then again, it begs the question of why bother with Windows as opposed to *nix in the first place... ;)

Re:1st step.

[godefroi]

Line endings aren't a problem for source control systems, they're a problem for development tools. If all your development tools were line-ending-agnostic, then your source control system wouldn't need to do line ending conversions.

Re:1st step.

[Anonymous Coward]

Uhhh no. TFS can easily run 1k users per server. Try not to look like a retarded neckbeard stuck in 2001 when you reply.

Git can scale to bajillions of users at a cost per user of roughly $0 when you exclude hardware costs. Team Foundation Server costs...$500 for the server and $500 per user or per device. (How nice--they let you choose which orifice to get raped in!)

Re:1st step.

[Anonymous Coward]

TFS is not based on Perforce. Microsoft bougth a source code license to Perforce and modified it to create Source Depot, which they use internally but are not allowed to sell. TFS is a wholly original project created to replace SourceSafe.

Windows and Office do use Source Depot, but Microsoft uses TFS for some projects internally, notably including Visual Studio.

Re:1st step.

[Anonymous Coward]

VSS is Visual SourceSafe, not Visual Studio.

VSS != TFS

MS Really Embracing OSS?

[Anonymous Coward]

Git the heck out of here!

Re:MS Really Embracing OSS?

[davydagger]

can't beat 'em, join 'em

said the same thing aboue apple with OS X

except MS's terms are ironicly far more reasonable

Re:MS Really Embracing OSS?

[jampola]

This. It's a sad day where if I were forced to give up my Linux's and BSD's I'd feel more comfortable moving to Windows opposed to OSX.

Ironically I am posting this from an Macbook Pro running Debian :)

Re:MS Really Embracing OSS?

[Beefpatrol]

I don't think that is why Apple based OSX on various open BSDs. Apple is and always has been a hardware company. They don't make money on software by itself like Microsoft does. They sell laptops that would sell for $800 with Windows on them for $2000 because they are the only laptops that run OSX without all sorts of hacking. (Yes, there are other reasons, but 95% or more of the reason they keep selling those laptops for that price is due to OSX.) When Apple embarked on OSX, they were circling the drain. They knew they needed a complete OS rewrite; they needed an OS that did preemptive multitasking. (Even Windows did preemptive multitasking then.) Apple was never in competition with software companies.

They did the smartest thing they could have done, which was to put an Apple-style interface on a free, high quality implementation of an operating system that was more than powerful enough to hang with the industry leaders, well understood by geeks, and which contained, essentially, the reference implementation of the protocols that the internet runs on.

At that point, lots of people, especially geeks, (geeks had recently become cool,) wanted to buy a laptop that ran "UNIX" and that had fully supported hardware that "just worked".

Re:MS Really Embracing OSS?

[slimjim8094]

Funny you're uncomfortable moving to OSX, since it is (essentially) a BSD. Though I suppose that means if you were forced to give up BSDs, you'd therefore be forced to give up OSX...

Re:MS Really Embracing OSS?

[Anonymous Coward]

As with Windows, it's not the OS that is scary, it's the company behind the OS. Apple has always been a much more controlling and anticompetitive company than Microsoft, it's just that they never had any marketshare to abuse until recent years.

Re:MS Really Embracing OSS?

[benjymouse]

They did the smartest thing they could have done, which was to put an Apple-style interface on a free, high quality implementation of an operating system that was more than powerful enough to hang with the industry leaders, well understood by geeks, and which contained, essentially, the reference implementation of the protocols that the internet runs on.

Were you around in 2001? I don't think "high quality" is a term anyone would use to describe those first versions of OS X. It was slow, user interface sluggish, riddled with kernel panics. Apple actually had to offer a free upgrade to 10.1 - which was still slow and sluggish but somewhat more stable. OS X eventually grew into a high quality OS, but those first versions were certainly not. Until Tiger it was kind of a joke, really.

Re:MS Really Embracing OSS?

[styrotech]

MS is now feeling threatened by the way other large companies (eg Apple, Google etc) are now 'cooler' and can now influence the software development ecosystem via their mobile platforms.

Open Source no longer really seems as much of a threat to them, and there's no point fighting it any more. And with Apple and Google increasingly becoming less open and losing some respect with the open source community, MS probably feels that they need all the help they can get to help keep them relevant or influential outside enterprise IT.

Re:MS Really Embracing OSS?

[samkass]

You're kind of ignoring the elephant in the room, which is that Apple didn't write MacOS X from the ground up. Most of it is NeXT with a different GUI, and which in the beginning had an integrated old-school Mac API grafted on ("Carbon", which has mostly been deprecated in favor of the NeXT's traditional API). NeXT chose BSD because it was done by Avie Tenavian, whose CMU work on the Mach kernel (which used BSD) became the core of NeXT's OS. They chose BSD because Linux didn't exist yet and everything else was locked down pretty tightly. So you're talking about an OS with roots in the mid to late 80's and decisions inherited from that time. It's probably on a short list for being among the longest-surviving continuously maintained OS in common usage today, predating NT, Linux, Solaris, and many others.

Re:MS Really Embracing OSS?

[Anonymous Coward]

Not to pick a nit, but the 10.1 replacement for 10.0 was *not* free. Jobs in his infinite wisdom said I had to pay $50 to replace the alpha called 10.0 with the beta called 10.1 on my brand new G4. (Some crock about "shipping and handling".) Way to slap your fan base, Steve.

Note: I had been using MacOS since the 6.x days back when you had to pay dearly for the Mac experience. I developed Mac software semi-professionally. You could say that I was definitely a fan. Throughout that time, OS releases were free. It was hardware that you bought. Hence there were a lot of us that were quite angry at the switch to paying for OS software after having spent a fortune on Apple hardware.

That so pissed me off that I left the Mac universe. Jumped to Open Source Software. Sometimes I have to roll up my sleeves but no one is forcing me into their vision of the future and making me pay for it. I am able to fix things with less time commitment than I would have to fix black box OSX or Windows and as an added benefit I actually understand what my computer is doing. It is all open and discoverable without needing to buy a book written by some insider. Those who opine that OSX or Windows "just work" (especially for non-geeks) are deluding themselves. To someone unfamiliar with either OS, it is nearly impossible to fix either of them by themselves. If they "just work" why do I get called upon as the family/friends tech support department. (Note: OSX is a bit better but still not worry free.) Once set up, I get less calls from Linux installations so tell me again why are the others supposed to be so much better?

Re:MS Really Embracing OSS?

[Eskarel]

Within certain contexts, they really do. Most of the frameworks in the .NET stack are open source now, they run codeplex which is a relatively thriving open source community, the licensing for the Windows store is actually really OSS friendly, mono is at least nominally sanctioned. They're not likely to Linux or LibreOffice any time soon, but in recent years if it's in their best interest or at the very least doesn't harm their bottom line, they're relatively pro open source. The days of "Free Software is Communism and must be destroyed" are long over at Microsoft, at least publicly(I don't work for them, so I have no idea how they behave behind closed doors).

Realistically they're substantially more open source friendly than Apple(apple utilize open source software and release exactly what they have to legally and not a drop more as far as I can tell). The core of their attitude is probably on par with Google(they'll open source pretty much anything they don't make money off of, but nothing that they do). Obviously Google's contributions to OSS are far greater, but the nature of the attitude is about the same.

For all that folks criticize current management and for all that it has a major problem with releasing unfinished ideas, the Microsoft of the 90's is, at least from all outward appearances, long gone.

Note that's not to say they aren't greedy, or that they like competition any more than they ever did, but it's not like it was.

Re:MS Really Embracing OSS?

[Beefpatrol]

Good point. I almost forgot about Next. Even if Apple made that decision because it was the path of least resistance, I can still say that I think it was probably the best decision they could have made. The fact that the BSDs are the oldest OSs in common usage today isn't a coincidence.

Re:MS Really Embracing OSS?

[PCM2]

You're kind of ignoring the elephant in the room, which is that Apple didn't write MacOS X from the ground up.

An equally important elephant in the room is that Apple had been trying to write its own modern OS, with features like preemptive multitasking and memory protection, from the ground up, and it failed. Once Copland crashed and burned, Apple had wasted so much time that it had no choice but to acquire an OS -- or at least the foundations of an OS -- from some other source. NeXT ended up being it.

Re:MS Really Embracing OSS?

[TheNinjaroach]

Were you around in 2001? I don't think "high quality" is a term anyone would use to describe those first versions of OS X. It was slow, user interface sluggish, riddled with kernel panics.

I remember all operating systems to behave this way in 2001. Linux and Windows were pretty much the same experience for me.

These days I think all three of them are quick and stable.

Re:MS Really Embracing OSS?

[davydagger]

there are more GNU and GNU related projects in OS X than neXt remnants.

remember that every time you connect with networkmanager, type something in on bash on the command line, etc...

Re:MS Really Embracing OSS?

[davydagger]

eye.

linux was not suitable for desktop use until kernel 2.6 era, when all the baked in drivers started appearing, and we started seeing open source factory support for things like wifi, and even then it wasn't until around ~2.6.30 that things started getting good enough to work universally on most computers around the board.

the nvidia 310.xx and later drivers are fast, stable, and solid. they used to not be, and nouveau is now feature complete for rendering. it used to not be.

Windows 95, 98, and ME where all inherently unstable, windows NT builds like 2000 where rock solid, and many people used them instead of the consumer focused products for this reason. unfortunately, 2000 still had a Hardware Accssability List, that prevented many third party drivers, and wasn't constructed for graphics intensive consumer desktop usage.

XP was the first Windows OS, that by design, didn't suck misrably, and it wasn't until service pack 2, in 2004, that it wasn't slow, buggy, or an otherwise total pile of garbage. Ironicly, this is around the same time that linux gets usable as a mainstream desktop OS.

Windows has its glitches and so does linux, but it seems with windows, they are all total OS problems, and with linux its generally high level interface problems. Vista crashed and burned, but 7 seems to be as rock solid as XP SP2, with modernizations, and newer hardware support.

Windows 8 on the other hand seems to be a trainwreck, with a crappy UI that no one likes, but we seem to have the same problem in the linux/FOSS world with GNOME. fortunately, there are other UIs than GNOME.

I guess you could run KDE on windows 8, and save yourself a fuckton of headaches.

Awww

[binarylarry]

But what really happened?

I bet Visual Source Safe ate the *real* Windows 8 and what was released was hastily put together over an ubercrunch weekend.

Re:Awww

[Jerslan]

You're thinking of Windows ME ;)

He Finally took my advice. Or is making Progress.

[Anonymous Coward]

http://futureoptimistnow.blogspot.com/2012/12/sent-this-letter-by-fedex-few-weeks-ago.html

Subject: Proposal for a Modern Distribution System

Dear Steve,

The current system in use to distribute Windows is highly dated. Outlined is a system, with pros and cons, that uses advanced encryption and checksums to ensure that each copy of Windows is perfect.

Use bittorrent protocol to distribute a free image of Windows
Create a static web page with a magnet link, allowing the user to download said image with a bittorrent client
Add a link to a rebranded version of “unetbootin” either by ftp or bittorrent protocol
Sell a USB flash device like the one enclosed with Windows branding

Pros:
Save money on server load costs; people will use the resources of the “swarm” instead of Microsofts
High level of integrity ( checksums, encryption)
Sales from usb devices
Eco-friendly with no plastic involved

Cons:
Uncontrollable distribution
Lawsuits from retailers? (cutting out the middleman and selling online)

Sub-proposals: (optional)

Recompile essential GUI components to integrate with new kernel
Allow user to choose between Windows XP GUI, Windows 7 GUI and Windows 8 GUI
Tailor each live image to individual markets, thus reducing the images size
Use WINE for backwards compatibility dating back to Windows 95

Conclusion:

The above outlined points would more than likely double Microsoft's stock within a short period of time. I realize these are major changes, but nothing ventured, nothing gained. Most of Microsoft's revenue is from deals cut with OEM partners pre installing a licensed version on each machine. Even if Windows was free, the majority of the population would still buy a new computer and thus pay Microsoft, versus downloading a torrent file and running the install themselves. Retain full copyright over the user experience and GUI components but use a world class free kernel for the backend. People would notice the difference in performance but still use the interface their comfortable with.

Putting a price on the software and making it a physical product makes Windows worthless. Upgrading the kernel and lowering the barrier of distribution would act as catalyst and make Windows Priceless and thus essential, like water, allowing continued market dominance. All in all, transcend your product from a toxic physical embodiment into a pure electronic eco-friendly one.

Call it “Windows Universe Edition” or some other hipster crap like that. People are bad with numbers.

PS: “Those who see the future, create the future.”

Git today

[abelb]

"Do more Microsoft GIT+" tomorrow.

Faith

[Anonymous Coward]

I want to be optimistic about their Git integration. We are migrating towards Git at work, and I can only hope it will help my fellow Windows developers have some nice tools on par with what we (Mac devs) have (a.k.a. SourceTree).

I hope they integrate git-flow somehow...

Re:Faith

[Desler]

TortoiseGit has existed for years...

Re:Faith

[aztracker1]

TortoiseGit has to be the most painful experience I've had for simple workflows... google and the command line were easier.

As to the why... Github is the new hotness for FLOSS projects. 'nough said... Though about half my dev time is now using NodeJS in Webstorm...

Re:Faith

[Barryke]

You should take a look at SmartGit and TortoiseGit.

Re:Faith

[DrXym]

There's also EGit for Eclipse. I use it and generally it works really well. It's a pure Java implementation (it uses JGit which also powers other tools) but its only a subset of Git which sometimes leads to trouble if you try and be too fancy with it.

Re:Faith

[Anonymous Coward]

Yes, but this also means using Eclipse which also means crying yourself to sleep each night.

Re:Faith

[dkf]

Yes, but this also means using Eclipse which also means crying yourself to sleep each night.

You mean, you wait to cry until after it has finished starting up in the morning and applying its updates?

Re:Faith

[Desler]

How is it painful. You right click and choose from the context menu. It's extremely easy to do almost anything the CLI does.

Good

[Murdoch5]

GIT is the best SCM software I've personally used. I fully support this move, there is no point on wasting money when you can a better version for free.

Re:Good

[Anonymous Coward]

Actually, among all the software started by Linus, git is by far the most impressive IMHO. The kernel is a large amount of work, but it's pretty bog down standard code. While git was written by someone with the experience of managing large projects to manage large projects, and it shows. I started with git at the time of the bitkeeper fiasco and converting my BK repositories was quite painful given the rough edges of git at the time, but now the interface is fine. Simple things are trivial to do, and complex things are made as simple as possible.

The only thing that was better in BK was the visual merge, although I've not done any merge in years, so maybe git has progressed in this respect.

Re:Good

[serviscope_minor]

GIT is the best SCM software I've personally used.

Have you used other DVCS? I've use Darcs (wonderful but a little flaky) and Mercurial and touched on Bzr. I've used git far more now since so many other things use it, but I don't see all that much difference between Hg and Git. Do you have an opinion on such matters?

Re:Good

[Murdoch5]

I've used Perforce which is by far the biggest pile of all. SVN was okay but has some strange issues that are just bone headed. CVS wasn't bad but again has it's own little issues. GIT just seems to work and work like I want it to, with no extra's that don't add to the software. GIT is exactly what it is says it is, it's a SCM that works. So far out of the ones I've used it's the only to really stick to that.

Lmftfy

[Milosch1]

Microsoft INVENTS Git For Development Tools. Community rejoices!

Re:Lmftfy

[Anonymous Coward]

Late to the innovation party as usual. Oh well, they can still roll out the relevant after the fact patents. Overly vague patents software patents are cool. Some day they'll be worth something.

Don't they use Perforce internally?

[CockMonster]

It's a pity there's no Open Source version of Perforce (yes, yes not everyone needs DVCS). They really panicked with the 2012 version though. I believe Google also use Perforce.

Re:Don't they use Perforce internally?

[VortexCortex]

(yes, yes not everyone needs DVCS).

Those... words. They stick like bullshit to my mind's shoe.
Everyone who doesn't need DVCS can simply use DVCS as centralized or local source control.

Re:Don't they use Perforce internally?

[Anonymous Coward]

There are plenty of scenarios where DVCS would be equivalent to taking a 10 pound sledgehammer to drive a penny nail. Get over your warped self important agenda and use the correct tool for the situation.

Re:Don't they use Perforce internally?

[Anonymous Coward]

It's the opposite. Git doesn't handle huge repositories, e.g. projects that are several times larger than the Linux kernel.

Git is perfect for small and medium sized projects, which constitute the vast, vast majority of projects. But it sucks for really huge repos. Submodules, obviously, are a hack which can't always be used to get around the problem.

Re:Don't they use Perforce internally?

[grouchomarxist]

It probably depends on the project, it appears that Perforce is mainly used, but git is also used. For example, the Android project uses git.

http://www.quora.com/What-version-control-system-does-Google-use-and-why

Re:Don't they use Perforce internally?

[the eric conspiracy]

Yes. Why don't they fix submodules? Everyone has some workaround to submodules. But nobody actually fixes it.

Re:Don't they use Perforce internally?

[Anonymous Coward]

Except git is basically simpler to use than all source control out there when it comes to decentralization. As in, it's easier to use git to get you running than TFS or SVN.

Re:Don't they use Perforce internally?

[aztracker1]

Sorry, but I have to disagree... Setting up SVN +TortoiseSVN on windows is pretty painless, and just works... Setting up a centralized Git repository is about like pulling teeth imho.

Re:Don't they use Perforce internally?

[sg_oneill]

git init

How hard is that?

Re:Don't they use Perforce internally?

[DrXym]

Submodules are a total pain in the arse. Git's achilles heel is definitely large projects and they need to be broken up some how though.

Another failing of git is for storing binaries where the project just bloats and bloats. If we were talking of a centralised repo, perhaps that wouldn't matter so much, it's *everyone's* clone that bloats and if you want a working clone, you have to clone everything, not just a snapshot. It means it's a really bad idea to store frequently changing binary files in git. I think Subversion would be a better choice for document management for example where people can checkout just a fraction of the server and aren't encumbered with bloat.

Where I work even uses CVS to commit nightly test results and thanks to the general craptitude of CVS they get away with it because it only ever holds a copy of the latest committed binary.

Re:Don't they use Perforce internally?

[Anonymous Coward]

Have you ever used GIT?

I use it for my personal projects. That is ONE developer (me).

I rejected alternatives (CVS, Subversion, etc) because they are too complicated to set up. GIT is really a light weight tool compared to the centralized solutions.

The size of the CVS setup howto is several pages. Subversion is even worse, and assumes that you are going to run Subversion under Apache (which would add another howto for setting that pile up securely), not standalone.

Setting up git howto can be written in one page. IF you use 72 point Times New Roman (maybe it needs to be larger).

"git init"

Re:Don't they use Perforce internally?

[serviscope_minor]

How hard is that?

Harder than it appears: you forgot the --bare

Re:Don't they use Perforce internally?

[Anonymous Coward]

funny. I've setup many revision control systems, rcs, cvs, svn, source safe (back in the day), perforce, etc. If you're worried about the one time cost, you're fooling yourself. Besides, how hard is it to setup perforce? Oh yeah that's right, ./p4d. Done. Next. Works perfect fine for your ONE developer scenario. So I ask, have you ever used perforce?

Re:Don't they use Perforce internally?

[Anonymous Coward]

You don't *need* --bare for it to work.

Re:Don't they use Perforce internally?

[Anonymous Coward]

Step 1. Download this
Step 2. Click through an installer.
Step 3. Create a repository.
Step 4. Download this
Step 5. Click through another installer.
Step 6. Check out your repo.

Wow that was hard.

Re:Don't they use Perforce internally?

[Anonymous Coward]

Step 3. Create a repository.

Anything looks simple when you have a single step that just says "do the thing"....

Re:Don't they use Perforce internally?

[jgrahn]

Submodules are a total pain in the arse. Git's achilles heel is definitely large projects and they need to be broken up some how though.

So far what I've seen is people breaking up projects in tiny little bits for no good reason, creating extra work and complexity. Look at Linux; it's just one repository, and Linux is large.

Another failing of git is for storing binaries where the project just bloats and bloats. If we were talking of a centralised repo, perhaps that wouldn't matter so much, it's *everyone's* clone that bloats and if you want a working clone, you have to clone everything, not just a snapshot. It means it's a really bad idea to store frequently changing binary files in git.

Apart from graphics work, when would you ever want to do that? (People checking in their generated executables deserve the pain, IMO. So do the ones who try to use MS Word for serious work.)

Where I work even uses CVS to commit nightly test results and thanks to the general craptitude of CVS they get away with it because it only ever holds a copy of the latest committed binary.

I never understood what's so crappy about not storing a lot of crud. I use CVS and Git, and I regularly use both without access to the central repository. Git is nice in many ways, but the "I can do everything disconnected" feature is vastly overrated.

Re:Don't they use Perforce internally?

[Anonymous Coward]

Sorry I didn't know I had to hold your hand. VisualSVN gives you a MMC console for managing the server, it even opens it for you after the install. You right click on repositories, pick Create out of the menu, and give it a name. Did you need instructions on how to click the OK button as well?

Re:Don't they use Perforce internally?

[terjeber]

Git is easier to use than almost anything out there, and completely useless for very, very large projects (the kind that makes Linux look tiny).

Re:Don't they use Perforce internally?

[Puff_Of_Hot_Air]

Linux is small. And it's just source code. Storing binaries happens a lot for a lot of reasons. You might have binaries for a third party library, you might have various art assets, compiled CHM files for help, installers for dependencies, etc etc. Git was designed for a particular problem space, in which binaries were not considered a big issue. Other groups have different requirements.

Re:Don't they use Perforce internally?

[TheNinjaroach]

Have you ever even tried Git for Windows? Right click anywhere and hit "Initialize" and you're done. It's ridiculously easy. Now that I think about it, I want to see what kind of integration I can get with Dolphin for KDE..

Re:Don't they use Perforce internally?

[aztracker1]

Command not found... Now install and configure got to work against a server in windows.

Perforce plugins... Egit

[Anonymous Coward]

Is this new? Perforce has had Visual Studio plugins for donkeys years, in fact every source control systems I've ever used has integration into VS and Eclipse.

So they now have a GIT plugin? And Eclipse has had EGIT for years. So basically they've only just caught up with the competition in that area.

And they're marketing it as "Hey wow, Microsoft is totally embracing open source", when it should be "Microsoft finally catches up to Eclipse and adds support for one of the major development source control systems".

Amazing

[Anonymous Coward]

It's amazing how one person can create the worlds most popular source code control system in his spare time while the herd of ass clowns in Redmond could only come up with the SourceSafe.

Re:Amazing

[UnknownSoldier]

Microsoft _bought_ One Tree Software in 1994 who originally created SourceSafe.

http://en.wikipedia.org/wiki/Microsoft_Visual_SourceSafe

Re:Amazing

[Anonymous Coward]

Brian Harry also built SourceSafe at One Tree Software, and then was the lead on TFS.

Re:Amazing

[DrXym]

Source Safe was easily one of the most evil source control systems I ever had the misfortune of using. Having to walk around to someone's desk to ask if they're done with a file is not my idea of a good system. Even worse when the file is locked and the person is on holiday.

Hardly 'embracing'

[Anonymous Coward]

Sounds like they are going to use it internally. That still doesn't mean that you will be able to report bugs to MS developers.

Re:Hardly 'embracing'

[benjymouse]

Sounds like they are going to use it internally. That still doesn't mean that you will be able to report bugs to MS developers.

Not likely. They already have TFS (or rather TFVS) which is pretty powerful. TFS is centralized and not based on a distributed model like Git. But each model has core advantages over the other.

Being centralized it is easier to create overview and centralize building, integrate with project management, testing, bug reporting etc. with TFS. But TFS is also focused on creating a single product and doesn't lend itself as easily to forking projects like Git does. TFS does branching and merging very, very well, but the central repository has to know about the branches, i.e. it is not so easy to create local ad-hoc branches.

Git is based on a decentralized model which is very, very good when you have a fluent number of products branching off from a repository. Git doesn't automatically expect a branch to be merged at some point, indeed the repository does not *know* about branches, it only knows about change/patch sets. However, the distributed model also means that there is no one central repository and you cannot use the repository to track *ongoing* work (who's working on what).

In some cases Git is better. In other cases the TFS model is better. If you have a distributed development model go with Git. If you have a very centralized development model go with TFVS.

Re:Hardly 'embracing'

[Anonymous Coward]

If you have a really centralized style of development, go for Bazaar, which you can coax into running the central style, but still use as a DVCS.

Re:Hardly 'embracing'

[DrXym]

I think the best thing about a decentralized model is the guys who run release engineering can run their own clone and pull when it suits them. And developers can work on branches, merge locally and test everything correctly to their own satisfaction before pushing. When everything is centralized it is not uncommon to see some email telling people a particular branch is locked for a merge, or for a build and it can go on for hours or days.

Re:Hardly 'embracing'

[benjymouse]

I think the best thing about a decentralized model is the guys who run release engineering can run their own clone and pull when it suits them. And developers can work on branches, merge locally and test everything correctly to their own satisfaction before pushing. When everything is centralized it is not uncommon to see some email telling people a particular branch is locked for a merge, or for a build and it can go on for hours or days.

But in TFS you can automate all that. TFS can build by label, by changeset or simply by point-in-time. Developers can pull specific versions out locally, also without branching. Only incompetent build engineers would ask developers to refrain from checking in. Really. Even as a developer I can request such a build.

This Bill's Solution ?

[Anonymous Coward]

To steal GIT !

This act of thievery will in Bill's words, 'My Plan To Fix The Worlds Problems.' http://indepthafrica.com/bill-gates-my-plan-to-fix-the-worlds-biggest-problems/#.UQnmYY7CEfM

Each step that William B. Gates III takes toward a grave, a very deep gravel, a grave filled with gasoline and torches at ready to ignite, is a step closer to fixing the world's problems !

XD

Not a big deal.

[Anonymous Coward]

This means nothing more than that they recogize how widley it is used, and understand that they will sell more of their own products if those products play nicely with it.

Eat crow, Microsoft fags!

[Anonymous Coward]

Have to stay current, don't we?

Ha Ha

[the eric conspiracy]

My boss is going to turn purple. He hates git & anything devised by Torvalds.

Re:Ha Ha

[Anonymous Coward]

Well, then he deserves to suffer.

Re:Ha Ha

[symbolset]

Is he a tall sweaty bald guy with excess enthusiasm? You would think they had told him already.

Re:Ha Ha

[Intellectual Elitist]

Same thing here. Our project has been using git for years, much to the chagrin of the least common denominator middle managers in our department. They've been pushing hard to get rid of useful work tools with "funny names" under the guise of a common tools initiative that was always in the bag for Microsoft. This will really stick in their craw. I love it.

Re:Ha Ha

[Anonymous Coward]

Also, did you see him throwing around chairs?

Re:Ha Ha

[mvdwege]

Naaah, he's probably called Larry.

Re:Ha Ha

[serviscope_minor]

This will really stick in their craw.

Well, it seems that Microsoft have just given Linus another step up in his ultimate goal: annoying people. Seriously, this seems to be his main aim and Linux and git appear merely tools (OK, excellent tools that I'd hate to do without) in this quest.

Re:Ha Ha

[alexgieg]

My boss is going to turn purple. He hates git & anything devised by Torvalds.

Truth be told, git isn't intuitive. I've been learning it in the last few days, and I still feel it works backwards (compared to what I'm used to think). Sure, in time I'll feel comfortable with it and start doing some of the amazing stuff I see mentioned around, but my, it's quite the steep learning curve!

I'd love it if someone were to write a set of detailed, hands on, step-by-baby-step, by-example tutorials, for different usage scenarios, showing the evolution of some real system being developed rather than abstracts "branch a", "tag b", "file foo.bar.1" etc., explaining command by command in long details that didn't assume you already knew what's going on. Everything I find while Googling, from the official site, to wikis, to tutorials, to blogs, even to actual books, including the most basic stuff, feels like I've jumped directly into chapter 10 of a work from which the first 9 have been ripped off. It's counter-intuitiveness taken to a whole new level...

Re:Ha Ha

[Anonymous Coward]

You should really take a look at the Pro Git book. http://git-scm.com/book

It assumes very little, and should be able to take any developer worth their salt from "lolwhat's source control?" to proficiency fairly quickly.

Re:Ha Ha

[Anonymous Coward]

I just got started with git as well and have been using this book as a guide: http://git-scm.com/book It's been pretty helpful so far.

Re:Ha Ha

[Anonymous Coward]

I'm with you there - even subversion I feel suffers from this. In fact, most OSS does.

Re:Ha Ha

[alexgieg]

You should really take a look at the Pro Git book. http://git-scm.com/book It assumes very little, and should be able to take any developer worth their salt from "lolwhat's source control?" to proficiency fairly quickly.

I did. It's one of the books I'm reading, and one I find very weak. It's all abstract concepts and toy examples, not git solving real problems for a real developer trying to do some real stuff.

My ideal git book would show git being added to an existing project, then used to develop it a little, then to test alternate features, then merge those that worked, going through the whole process of resolving a set of conflicts (real code conflicts, with a real solution, on the real project, step-by-step, not "foo.bar here differs from foo.bar there, solve it and mark as solved then commit" or the some other such generality), setting stable versions, doing stuff on those etc., with extensive discussion of what was going on behind the scenes, at the file system level, of all the people involved, for every high-level activity.

Re:Ha Ha

[degeneratemonkey]

I agree completely - it's not intuitive. But once you have the "Aha!" moment and everything makes sense, you realize that it's not only brilliant, but also really difficult to explain to someone else who doesn't get it yet. As someone once infamously tweeted (it's a joke):

Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.

But really, think in graphs.

Re:Ha Ha

[foniksonik]

Wow are you over thinking it. I've got two older female UX designers using GIT to manage their XML based wireframes. they create repos, add existing files, setup a dev branch, make changes, create feature branches in GITflow, merge features into dev, resolve conflicts, merge to dev, tag, create release branches, tag, merge to trunk.

Yes they've had help but it wasn't more than the examples you've described.

They are using SourceTree, so that could help.

Re:Ha Ha

[alexgieg]

I've got two older female UX designers using GIT to manage their XML based wireframes. they create repos, add existing files, setup a dev branch, make changes, create feature branches in GITflow, merge features into dev, resolve conflicts, merge to dev, tag, create release branches, tag, merge to trunk.

This. What I'd love would be to see a week of this on paper (well, screen), no step excluded, even if without any explanation of the commands, as I could look them upon elsewhere.

Re:Ha Ha

[Anonymous Coward]

I really don't get what the problem is. Why not just find a quiet spot for an hour or two, then sit down and learn it? Even for a neophyte it shouldn't take more than an hour to become productive with git.

Re:Ha Ha

[alexgieg]

Why not just find a quiet spot for an hour or two, then sit down and learn it?

That's not the problem. I already figured the commands I need to use "right know" to have things moving. That isn't the same as understanding what's going on, much less understanding the principles behind git's process and why they are as they are. When it comes to development tools, being an end user doesn't work for me. I want to fully grok them, not merely go with the motions. And so far git has eluded me. Using it in this way is like "knowing" an equation by rote memorization alone, without any real understanding of why the result is what it is or what it means. And this is just... wrong.

Re:Ha Ha

[Anonymous Coward]

I was in the same boat as you for a while. You just need to slow down and actually read the documentaiton and the tutorials.

One of the biggest gotcha's of learning git, is trying to be too smart and assuming it's like SVN. Just remember that when you run 'git add ' git will make a snapshot of that file at that moment in time. But adding a file doesn't mean it's commited to your local repo, instead it's in a kind of pending state. Once you run 'git commit' then the files that are in the pending state get commited to your repo, and written to the history.

The whole point to the way git does things, is to make it really easy to work on your code on your own machine, seperate from what everyone else is doing, and then having the tools to pull in other people's changes or push your own changes out.

Re:Ha Ha

[Anonymous Coward]

Then use the best. Use Mercurial

GPL Breaks this process.

[anwyn]

The GPL restricts the "Extend" step so that Discontinue step is impossible.

Any derived work of something, like git, which is GPLed, must be GPLed. That means that if you fork, the main branch, the main branch is free to use your extensions. This makes it difficult for replacement to work.

Furthermore, if you try discontinue step, others are free to fork and continue. So discontinue does not work.

The GPL completely breaks the "Embrace. Step 2: Extend. Step 3: Replace. Step 4: Discontinue." process. Which is why it is hated.

Re:GPL Breaks this process.

[Anonymous Coward]

I bet Microsoft finds a way to soft-Tivo-ize git anyway.
"Something something ... DMCA ... something something... criminal charges ... something something."

Re:GPL Breaks this process.

[Anonymous Coward]

No, the GPL completely allows it.

1 Embrace, 2 Fork, 3 Ship your fork with common development tools, 4 incomparable changes to MS-Git (which is now the "standard" as it ships with VS).

Now you *could* take the changes in MS-Git and push them back to Git but that does not mean you should or the project owners would.

Re:GPL Breaks this process.

[ledow]

The GPL stops it happening WITHOUT SOURCE.

But to be honest, in some cases source from places like Microsoft (and even things like OpenOffice) has been given to people who then just go "Urgh, why would I want to use that?!". The first thing LibreOffice did when they got their hands on the OO code was to rip things out and start again, start removing Java dependencies, removing lots of obsolete junk, and replacing the really crap code.

The source alone is not sufficient to do this.

Imagine, if you will, Microsoft "contributing" to Samba - let's say they contribute a fully-compatible AD implementation, to take an example of something that's desired and highly-sought after and certainly in MS's power to deliver. Their changes are bound by the GPL, too.

But that doesn't mean that if they slapped in ten metric tons of crap into Samba that it would be accepted and pushed as-is, nor that it wouldn't create a "Microsoft-free" Samba to clean up the code while the "Microsoft-tainted" Samba provides functionality.

Or what if they've dropped in a load of code that makes Samba work better, but only compiles on/for Windows systems, or isn't 64-bit safe, or isn't thread-safe. Sure it's "progress", but is that useful to the project as a whole? Maybe you can sit down and clean it up and make it work as intended, or maybe the effort of doing so is worse than just writing it all again from scratch.

A code-drop is, in and of itself, only the very, very first part of the process of actually integrating code into a project. It's the "easy" bit, especially if you don't give a crap about code quality.

But the biggest danger, is that MS takes Git, adds proprietary extensions and then just code-dumps their changes and abandons them. Then you have a million people who wonder why your git server isn't compatible with their git client from Microsoft, why you don't "just get it working" (even if it does horrendous things like lets users delete git histories or needs to run as root or whatever), and your left to manage the mess for eternity even though you have nothing to do with MS themselves.

Embrace, Extend, Extinguish.

We're at the first part. Same as we were for many, many, many ideas that Microsoft took (AD is the perfect example - a bastardised version of Kerberos, LDAP, that isn't compatible with anything else, which is why Samba 4.0 has to bundle it's OWN Kerberos, LDAP etc. servers that operate in the "Microsoft way").

Re:GPL Breaks this process.

[MajroMax]

Any derived work of something, like git, which is GPLed, must be GPLed. That means that if you fork, the main branch, the main branch is free to use your extensions. This makes it difficult for replacement to work.

I think that neither the on-disk nor wire protocols of git have special copyright protection. If it so chose, Microsoft could develop a fully closed-source git implementation from scratch that is "fully compatible" with, say, git1.8 but has proprietary Windows extensions.

Re:GPL Breaks this process.

[bheading]

Gentlemen,

If you look at libgit2 you'll see an exception has been added to the top of the license such that components which link libgit2 (either statically or dynamically) do not have to release their source under the GPL.

It's an absolutely excellent idea. Git is a solid, high quality piece of software and it benefits everyone who works in software engineering to see it integrated everywhere including on Windows.

A younger generation at Microsoft

[joelwhitehouse]

Is a younger generation of developers influencing Microsoft? The last few rounds of college grads on the management fast track at MS have had time to play with git in high school, college, and even perhaps as a personal tool at work. Maybe their personal preferences are affecting the Microsoft feature set.

Re:A younger generation at Microsoft

[DarwinSurvivor]

No developer of any kind has been in charge of Microsoft since Bill stopped writing their code. Balmer may have chanted (literally) their name, but they still had no power what-so-ever.

Re:A younger generation at Microsoft

[serviscope_minor]

Is a younger generation of developers influencing Microsoft?

I know a few Microsofties from my generation and older, and it's been a while since I've been a student. They've been using git on the sly for a while. Microsoft has a strong dogfood policy, but their VCS dogfood is really really awful.

Re:A younger generation at Microsoft

[degeneratemonkey]

This is guaranteed to be true. Younger developers exist, can develop software, and are generally cheaper than older developers. At some point it makes sense - if nothing else for the sake of efficiency - to adopt tools that people already know, especially if this means dumping fewer training resources into new hires.

There is a reason Oracle dumps billions of dollars into universities who train kids to program Java.

Re:A younger generation at Microsoft

[Admiral_Grinder]

I wonder that myself. A lot of people I graduated college with in 2004 in Computer Science work for Microsoft. Funny thing is that our school was very much Linux focused and these same people wanted nothing to do with Microsoft.

Say it ain't so

[Anonymous Coward]

Git has to be, hands down, the buggiest nightmare I've ever dealt with. Something, anything is better than Linus's evil spawn.

Re:Say it ain't so

[hag3r]

Git has to be, hands down, the buggiest nightmare I've ever dealt with.

Care to elaborate?

Re:Say it ain't so

[markkezner]

Counter intuitive? Yes, it most definitely is at times. Buggy? Not in my experience, it actually works quite reliably.

Maybe you just don't understand git. Or you're a troll.

Re:Say it ain't so

[cbhacking]

I've had trouble with pushes containing multiple commits that include changes to the same binary file, but I'm running an unofficial port of Git that is probably a bit out of date even if there isn't an actual issue in the port itself.

GIT certifications by Microsoft

[Anonymous Coward]

Their ASP.NET certification now includes jQuery, the ballz of Microsoft to ask for something they didnt invent. Oh well, so it is..

zombies, Von Dutch, and git

[bcrowell]

Zombies were cool. Then they got so overexposed that Homeland Security started making videos about the zombie apocalypse. Zombies are now as uncool as Von Dutch.

If MS is using git, it's obviously time to switch to something that is way newer, way cooler, and doesn't actually work.

OMG!!!!!

[Anonymous Coward]

OMG!!!! Microsoft is coming down with CANCER!!!! Quick someone get me a chair while I preform the ritual monkey dance. I. Love. This. Company! WHOOH!!!!!

I think that covers highlights.

No TFS?

[forgottenusername]

I'm still waiting for my formal apology from them. Such a turd they unleashed on the world - they quit using it internally on any sort of scale because it sucked, but continued selling it and a few places are still infested with it. Including legacy code at my shop.

Re:No TFS?

[jader3rd]

they quit using it internally on any sort of scale because it sucked

Part of the reason why is because the group that created TFS (DevDiv) views its target audience as lone wolf star programmers, working in their garage, just waiting to become to next big thing. It's in all of their vision documents, and all of the profiles they make up for most of their targeted audience. Since they needed to dogfood it, they got it scale by the 2010 release. It's core problem though, is that all of TFS's designers must have only worked in that group and don't know anything better. I swear they must be actively avoiding even thinking about any possible comparisons to competitors.

Re:No TFS?

[Anonymous Coward]

Awww, somebody needs a hug...

Re:No TFS?

[Eskarel]

TFS is actually quite good now, the problem is that like nearly all of Microsoft's good ideas, the first release(s) kind of sucked(Vista, Windows Phone, Windows 8, IE7/8). You can see where they're trying to go, but it doesn't quite get there in the end. I think the problem is that while they allocate absolutely ridiculous amounts of money into R&D and usually end up in the right place, they always feel for whatever reason that they need to get a version out quickly. That wouldn't be so bad of course, but their current release cycles sort of mean that those releases stick around longer than they probably should.

Re:No TFS?

[Anonymous Coward]

It seems they have the habit of acknowledging products were bad well after they stop selling them. Windows ME was wonderful when they sold it, it only became their most instable OS much later. Same pattern for Vista. Acknowledging past mistakes is not the same thing as apologising or taking product responsibility seriously. I'm still waiting for that free upgrade from ME to XP. I use Debian in the mean time.

Re:No TFS?

[Anonymous Coward]

I don't think "First Release" means what you think it means.

Re:No TFS?

[Eskarel]

I was referring to first releases of ideas not first releases of products. Windows 8 is obviously not the first release of Windows, but it is Microsoft's first stab at an OS which works in a touch and desktop environment. The core windows stuff is actually pretty great, the desktop/touch part(which is the bit which is new) is an abomination unto nuggen and must be scoured from the earth. Similarly Vista is Microsoft's first attempt to try and modernize their OS and enforce any kind of significant security whatsoever, it sucked(7 was pretty damned good though). IE7/8 are Microsoft trying to build a standards compliant browser and they suck, 9's not so bad though.

Fundamentally Microsoft releases their ideas half baked, and they do it a lot. When they actually finish baking the idea it's often quite good(I personally think that Microsoft can make an OS which functions on a phone a tablet and a desktop, at least they can if they stop thinking that embracing touch means no one wants to use a mouse anymore, whether they will or not, who knows).

.GIT?

[Anonymous Coward]

No thanks!

Battered wife syndrome. They won't do it again, re

[raymorris]

Some Slashdot readers are like a certain type of abused spouse who keeps finding someone to abuse them, and actually believing that he won't do it again. Fool me once - shame on you, fool me twice - shame on me, get fooled for 30 years running - you're deliberately choosing to be an idiot.

but...

[SuperDre]

they already had Git support.. so what's new?

Sometimes hard. Fiance wouldn't let me git init

[raymorris]

git init How hard is that?

Sometimes pretty difficult. My fiance told me there was no way I was going to git init.

Re:Sometimes hard. Fiance wouldn't let me git init

[foniksonik]

Especially not --bare

Re:Sometimes hard. Fiance wouldn't let me git init

[Anonymous Coward]

So I guess it'll stay hard.

More info here

[Big Hairy Ian]

http://tfs.visualstudio.com/en-us/home/news/

Basically they've rolled out Git support for the latest TFS Service release that means a full patch for TFS2012 & VS2012 should be out in 4 - 6 weeks.

So what?

[Anonymous Coward]

It's ok, that Microsoft will discontinue their Git involvement. Git itself will also be replaced by a better tool. Somewhen.

For now Microsoft acknowledges the quality of Git. That's great.

Git vs other VCSs

[JigJag]

I have taken a cursory look at Git but never really developed with it. I understand most of its fundamental characteristics however.

Personally (and professionally), I chose fossil for my development needs. It's small, fast, correct (so far Git is the same), easy, and integrated with a bug tracker and a wiki (all which cannot be said of Git). The author is no lame duck either, he's the guy who created SQLite.

If you're about to start doing decentralized development, check it out. It's worth your time.

JigJag

Re:Git vs other VCSs

[Patman64]

Zed Shaw wrote a post about moving mongrel2 to Github from Fossil, which can be read here: http://sheddingbikes.com/posts/1306005291.html. I don't have any experience with Fossil so I can't really say whether it was his fault or not, but whatever happened was bad enough for him to ditch it for git. Does anyone know what he might be talking about?

Today's weather report for Hades:

[Firewheels]

Cold and snowy, with occasional flurries of flying pigs.

Does it really matter?

[Anonymous Coward]

Most developers for MS products don't really know about Open Source. Don't get me wrong, there are people out there that know about it. They are the ones who are passionate about programming. Most people aren't. To most people it's a job. To those people, Microsoft invented ftp, the web,and computers. To them, Git will just be another Microsoft product and they will gladly pay.

Then you will hear how MS has revolutionized source management.

Anyone else had better luck?

[Prien715]

So I work at a Fairly Large Company (TM) and we recently downgraded from SVN to TFS. For years, I used the Git-SVN bridge which worked quite well.

The TFS/Git project, I'm sorry to say, so far DOA for an enterprise user like me. Git-SVN would take a many hours to migrate a large repository...but it worked. MS's Git integration has fallen far short. While checking out shallow copies works, deep copies crash on checkout (it runs out of memory, which really shouldn't happen). Even trying to get the latest version (i.e. git rebase in TFS parlance), it manages to flood my 16 GB system and die down in authentication. ...but I really think this is a good direction. I hat^H^H^H love TFS but being able to use Git is really useful. The lack of locks on all the files are particularly useful when doing large-scale edits with scripts/a good IDE and local branching is killer so I'd really like Git to succeed here.

I'd be curious as to what experience others have had with it in The Real World, rather than the chair-throwing annuls of MS HQ.

Re:Battered wife syndrome. They won't do it again,

[Anonymous Coward]

"Some Slashdot readers are like a certain type of abused spouse who keeps finding someone to abuse them, and actually believing that he won't do it again. "

      Ok, which group are you complaining about again? Slashdot readers hate Microsoft because they know it will do it again. That why they hate Microsoft. The trouble is the bastard won't go away and we can't get rid of him. Besides it's not on slashdot.org's interest for Microsoft to go away, you know, pageviews.

Support for lame developers

[spuk]

The main reason developers wanted TFS where I worked were 2:
* locking files, the most dumb (VSS) way, so other developers wouldn't change files someone else was already changing...
* the "shelf", i.e. to be able to backup current code to the server without it going into the main development branch...

In other words, they wanted TFS because of its support for lame developers, not because of the cool features...

Good.

[Alex Belits]

Now if only they abandoned all other crappy software they are using as a part of development process. And by that I mean, the content of their sources.

For a limited time only

[Anonymous Coward]

git reflog is handy but references a volatile store: the log of who did what when expires and is garbage collected every 90 days by default.