[tambourine_man]

It's interesting how all the cool things seem to come from Microsoft these days.

I still think we need something better than Git, though. It brought some very cool ideas and the inner workings are reasonably understandable, but the UI is atrociously complicated. And yes, dealing with large files is a very sore point.

I'd love to see a second attempt at a distributed version control system.

But I applaud MS's initiative. Git's got a lot of traction and mind share already and they'd probably be heavily criticized if they tried to invent its own thing, even if it was open sourced. Will take a long time to overcome its embrace, extend and extinguish history.

[Analemma_]

> I still think we need something better than Git, though. It brought some very cool ideas and the inner workings are reasonably understandable, but the UI is atrociously complicated. And yes, dealing with large files is a very sore point.

Note that Google and Facebook ran into the same problems Microsoft did, and their solution was to use Mercurial and build similar systems on top of it. Microsoft could've done that too, but instead decided to improve Git, which deserves some commendation. I'd rather Git and hg both got better rather than one "taking over".

[aanm1988]

Google uses some variant of perforce, just like MS has been doing.

[voxic11]

They used to, but now they use Piper which is built on top of mercurial.

[delroth]

Piper is not built on top of Mercurial.

[voxic11]

Sorry, you are right, I got it confused with some other work Google was doing to improve the scalability of mercurial. It's not based on perforce though either, appears to be entirely custom technology.

[stp-ip]

They first outgrew git, then outgrew perforce and implemented a custom server on top of their usual storage/database stack.

[severino]

> Microsoft could've done that too, but instead decided to improve Git,

They didn't improve git, they only made this for themselves and for their product users. Git doesn't restrict you to a single operating system.

[Kipters]

Look at Issue 4 on their GitHub repo, they want to port it also to Linux and macOS

[askvictor]

> They didn't improve git, they only made this for themselves and for their product users. Git doesn't restrict you to a single operating system.

Given Microsoft's recent form, I'd expect this to appear on Linux before long, and possibly osx too. In any case, it's open source so you could always port it yourself.

[Sir_Cmpwn]

I would be surprised. This sort of project is deeply OS-specific. If they wanted to eventually make it cross-platform, they would have started by implementing FUSE on Windows.

[zintinio5]

Several years ago a friend and I had a need to build a virtual file system that was portable between Linux and Windows. At the very least, we attempted to share as much code as possible. It proved to be pretty easy and we had a working prototype after about 30 hours of work. We used FUSE on Linux, and Dokan FUSE on Windows.

[1] https://dokan-dev.github.io/

[2] https://github.com/dokan-dev/dokany/wiki/FUSE

[severino]

> In any case, it's open source so you could always port it yourself

Of course, but that would be me, and not Microsoft, who's improving git ;-)

[verytrivial]

> It's interesting how all the cool things seem to come from Microsoft these days.

I've assumed Microsoft have been making all this stuff all along, but keeping it internal then throwing it away on the probably false assumption that every bit of it is some sort of competitive advantage. I think they're coming around to the idea that at least appearing constructive and helpful to the developer community will help with trying to hire good developers.

[sytse]

Maybe something that has the data models of git but has a more consistent interface? Today on Git Merge there was a presentation about http://gitless.com/

For example one of the goals is to always allow you to switch branches. Stash and stash pop would happen automatically and it would even work if you're in the middle of a merge.

[Ajedi32]

I'm still waiting for a decent GUI that takes full advantage of the simplicity of git's underlying data model. The CLI is okay and I've gotten really good with it, but fundamentally I think git's DAG is something that would be best represented and manipulated graphically.

[Reinventing the Git Interface][1] was written almost 3 years ago now and yet to my knowledge nobody's implemented anything quite like that yet.

[1]: http://tonsky.me/blog/reinventing-git-interface/

[daxelrod]

Git Kraken has some neat ideas around dragging bits of the DAG around to manipulate them.

[Ajedi32]

Yeah, I've been meaning to try that for a while now. Unfortunately I can't use it at work because Kraken still don't support connecting to the internet through a proxy, and they won't let you use it offline.

[StavrosK]

I quite love both the motivation and the implementation of gitless (and the choices they've made). I find it much more usable than git.

[tambourine_man]

I'd never heard of Gitless, I'll check it out, thanks.

[coherentpony]

> I'd love to see a second attempt at a distributed version control system.

Out of curiosity, why a whole new attempt? Personally, I'd prefer the approach of "making our current tools better."

[gumby]

"Let a thousand flowers bloom." Competition helps both sides. Clang became good enough that it spurred GCC to become a lot better.

Until 1997, forking a project was considered a tragedy. I think things have improved since then :-).

[coherentpony]

Fair point.

[moosingin3space]

What are your thoughts on Pijul? (https://pijul.org)

[madgar]

I'd love to dig into Pijul but sadly it's AGPL. Just looking at the code effectively taints me as a developer who works tangentially to VCS - it could be argued that my work is derivative and thus needs to be AGPLed. The viral nature of the license then creates an existential legal risk to my employer.

[ska]

   I'd love to see a second attempt at a distributed version control system.

Git wasn't the first, and even then had several contemporaries at 2nd gen.

[toyg]

Yup. I remember when git came along the field was already pretty crowded (DVCS, Darcs, Bazaar, BitKeeper, Mercurial...). I've always suspected Linus wrote git in a panic simply to sidestep the months of flames that switching VCS again would have inevitably generated, once BitKeeper stopped being viable. I also remember people jumping at the occasion like they would have never done to improve someone else's tool.

The story of git is a good case-study for people interested in group dynamics.

[WorldMaker]

I agree, the story of git is a good group dynamics case-study. I watched a small bit of it from mailing lists at times.

I was a heavy darcs user at the time and the impression I got was part of the name git in the first place was that it was intentionally the "dumb, dirty, get things done" answer to darcs' (sometimes problematic) smarts. (Remember, the British slang definition of git is "an unpleasant or contemptible person".)

It's also interesting that both Mercurial and git were spun out of the BitKeeper fiasco (BitKeeper was a commercial product that allowed free hosting for Open Source projects, up until the fiasco where they decided they were bored hosting Open Source) by Linux kernel members. Mercurial actually wound up with lead and if I recall correctly was much more usable faster than git was. The problems with Mercurial were that it was written in Python and git was lead by Linus himself and in the apparently more preferable to kernel hackers C, perl, bash, awk, sed, spit, and duct tape development environment.

[madgar]

The problem for Mercurial (with respect to group dynamics) was that it didn't have the built-in user base of Linux contributors right off the bat.

[WorldMaker]

I briefly glossed over it, but Mercurial could have had the Linux contributors right off the back. It was built faster than git and was built with the kernel team in mind. I do think it is an interesting bit of group dynamics that the kernel team as a whole didn't adopt Mercurial (because there were kernel team members on both sides of the Mercurial/git divide), and some of that reason seemed to be, from what I read at the time, simply a dislike of Python by a surprising number of kernel team members.

[blunte]

Indeed, but I also had a pause when I considered how heavily Microsoft depended on a system originally built by Linus Torvolds :)

[ma2rten]

Mercurial is very similar to git but more user friendly.

[Florin_Andrei]

> It's interesting how all the cool things seem to come from Microsoft these days.

It's like a whole'nother company after they got rid of Steve Ballmer.

[Piskvorrr]

Meh. If I'm watching the 3E cycle right, they're currently in the Embrace phase and heading to Extend. And it's been a cycle for a number of repetitions - it doesn't take a genius to see where it goes next.

[greyman]

> but the UI is atrociously complicated

Linus himself admitted that he isnt good at UI. Anyway, I think git just wasnt designed to be used directly, but via another UI. For example, I use it within Visual Studio Code, and that covers about 90 percent of usecases, and then Git Extensions can take care of almost everything else. Sometimes cli is needed, though.

[sjellis]

Git Extensions was a fantastic project back when the idea of Microsoft supporting Git would seemed impossible. It made my life better everyday when I was a C# developer. These days, I use the Git CLI on Windows, but VS integration with Git seems good, so I haven't felt the need to install Git Extensions.

I've still not yet seen a stand-alone GUI for Git that is better than the one that ships with Git Extensions, though.

[aairey]

What a change of cash-cow placement can do ...