>A lot of smart people don't.

I'm sorry, I don't buy this at all. Git is one of the most simple source control tools there is. If you can't understand a DAG then there isn't much else you probably can understand in the development world.

>This manifests as frequent unintended results

No it doesn't. Every time I've seen people complain about "unintended results" it's literally been because of the above, and they've been complete morons so I'm never surprised when these people have "trouble" with git. You're building a graph, and you're doing pretty basic manipulation of that graph.

>I never had any such problem with Perforce

Uh what? Permission issues? Terrible branch performance? Merging between branches is basically a gamble -- it's actually insane how much this used to mess up over the most basic of merges. Having to "upgrade" the system? Ever done that. I'm going to guess no.

I can run circles around most of my fellow developers working with Git. I know how to recover from almost anything I do with Git. However, I put in a lot of hours to get there. I have nothing but distaste for Git's command line. It's an abomination. The command line flags are inconsistent and require real work to commit the right combinations to memory. Anyone, whose solution to this is "You are an idiot for getting confused by this confusing UI" is just flat out wrong. There are better UI's that are less confusing with the same featureset as Git. Git won not because it was that much better than the others. It won because the Linux kernel uses it.

Right now today, there are developers out there who are putting in the work to learn git. They are smart and dedicated to their craft. They are also losing work because git makes it easy to shoot yourself in the foot and because it doesn't easily surface to you how to recover when you do so. It's not because the developer is an "idiot". It's because git's UI is user hostile and does a poor job of reflecting the core concepts in operation when the user is using it.

To be fair to Git they've put a lot of effort in fixing this. It used to far worse than it is now. But due to backwards compatibility and other concerns there is still a lot confusing and unintelligible options out there and that is even after you get the whole concept of a DAG and the index vs working tree.

> Git won not because it was that much better than the others. It won because the Linux kernel uses it.

This is a pretty silly assertion to make. You're actively ignoring the SCM's that were chosen by far larger org's. Git took the dev world by storm because it was better. Not because an open source OS used it. Other SCM's had years worth of developer training and interaction with their systems and STILL lost. Years worth of sales connections, demos, networking, you name it and STILL lost.

>They are also losing work because git makes it easy to shoot yourself in the foot

Example?

>Example?

Most people can get the quickie commands down pretty fast, and as long as there are no complaints or errors, it's all OK. But as soon as you need something that takes several steps, your average git user falls apart. Rebases are the most common example. If you don't block force commits from the get-go on a project used by more than two devs, you'll learn that you need to do that pretty quick.

Exactly. Many users get confused and a quick look at the man page shows them a magic --force command that seems to do what they want. Not to mention that we sometimes encourage the use of --force sometimes when we are doing pull requests since we want them to push a squash of all the different commits. It's like a tragedy of the commons playing out in multiple dev teams the world over and it didn't have to be that way. The problem is no one took the time to devote some UX to the git command line until it was too late.

- https://stackoverflow.com/questions/10099258/how-can-i-recov...

- https://stackoverflow.com/questions/10099258/how-can-i-recov...

- https://www.clearlyagileinc.com/blog/recovering-commits-from...

Everyone of these is an example of the git UI/UX confusing you about what is happening. Reflog allows you to recover if you know about it but if you don't you will feel betrayed by the tooling. Blaming the developers for not knowing what Git was going to do is ignoring git's bad ui/ux decisions. Mercurial for instance doesn't have this problem. In fact it tells you whenever you do something that might lose data that it made a backup and where it put the backup at. Everything the developer needs to know right there after they accidentally shot themselves in the foot trying to do their job.

     Other SCM's had years worth of developer training and interaction with their systems and STILL lost. Years of worth sales connections, demos, networking, you name it and STILL lost.

You are comparing Git to high cost options like Perforce which lost because they were expensive and OpenSource doesn't like expensive proprietary solutions in a field where OpenSource rules. I'm talking about solutions like mercurial which have a similar underlying model and a better user experience out of the gate. Git beat hg not because it was better architecturally. They have the same underlying datamodel. It won because the linux kernel used it and that gave it the necessary cachet and authority by association. This is not bad git is worlds better than perforce or cvs or svn in many ways. I'd rather use git than most of those in most situations. But I also would rather use hg than git any day because it's the same datamodel with a ui that doesn't mislead me.

>Everyone of these is an example of the git UI/UX confusing you about what is happening.

Um, I don't see it. Your first 2 links are the same question. All "3" examples basically give you a single command to run to get your work back. What's confusing?

> Mercurial for instance doesn't have this problem.

WHAT? Mercurial actively changes the underlying data objects it stores and there is NO WAY to get them back. Rollbacks actively delete content and you CAN'T restore them, shuffle them around, or anything like that. You do have the Journal extension but it's not apart of the core product. And people definitely haven't had problems with extensions before ;). See: https://book.mercurial-scm.org/read/undo.html

>In fact it tells you whenever you do something that might lose data that it made a backup and where it put the backup at.

So does git. Every operation that Mercurial gives you a warning about git does as well. Even better, git still gives you a way out even if you do the thing you shouldn't have done. It warns you in the prompt, it warns you with comments in the text editor of your choice that pops up for input.

Is there some operation you can give an example of that git lets you do that Mecurial somehow magically prevents or gives you a way out of?

>You are comparing Git to high cost options like Perforce

And what about the other opensource SCM's that lost?

>They have the same underlying datamodel.

They do not.

>I'm talking about solutions like mercurial which have a similar underlying model and a better user experience out of the gate.

It definitely does not. Not sure what you want but I'll take practical solutions like git being able to handle partial checkouts, branches, and blames over a nice gui. Git may have inconsistent command flags but it still does what you need it to.

>use hg than git any day because it's the same datamodel

You keep saying this but it's definitely not true, hence hg's limitations on certain operations. https://stackoverflow.com/a/1599930

I would like to hear some examples as well. I hate losing my work.

Please don't be that guy. You saw people having issues with git. Have you tried explaining why they ran into those problems and tried to find out where the misunderstanding came from? It's easy to criticise about what you already know. But everybody's experience is different. There's a practical issue with mapping every command to each copy of the dag, that people sometimes don't get.

If you haven't learned about urbit yet, you could try that for the same "I don't know what you're talking about" experience in your life.

> Have you tried explaining why they ran into those problems and tried to find out where the misunderstanding came from?

Of course? I'm also free to call them idiots online.

>There's a practical issue with mapping every command to each copy of the dag

That is certainly the most valid criticism of git, in my opinion. And certainly the biggest learning curve for most people. But that's not where people tend to have true, blue operational issues in my experience.

This is why some devs shouldn't design UIs, for many people their source control is simply a UI that they want simple with simple workflows. I know people with PhDs who just don't understand git, not because they can't understand DAG, they simply don't want to have to understand it in relation to a tool. The biggest thing with Git is you have to invest time into understanding it, that alone is one of its failings and hence why there is so so so many guides that try to give advice to people who don't really want to understand it.

>they simply don't want to have to understand it in relation to a tool.

There isn't a way around this. With any tool, especially when dealing with SCM. You have to understand how your selected tool is going to perform certain operations because it's going to dramatically effect your workflow with that tool.

>The biggest thing with Git is you have to invest time into understanding it

Just like you have to do with every other SCM, or just generally any piece of software?

The difference is that most other SCM's don't actively lose your work while you are learning.

Git doesn't do that. Perforce and TFS definitely will. The very moment I add something to the index it's basically recoverable. I'm not sure what you're really getting at here.

So I'd like you to prove that git won't lose work. Even smart people who use git have typed stuff that made them lose work.

You can, and will, argue they are morons. That's an excellent way to deal with a poorly designed system.

>So I'd like you to prove that git won't lose work.

It does not "actively" lose work. Losing work in Git is a pretty specific operation and generally requires you to spell out what's going on (either via 'reset' or 'checkout'). And also less likely to happen, since you are regularly using the index to stage changes and should be commiting often (since it's cheap to do, unlike trying to commit in BitKeeper, let's say, where locking problems sometime even require to change the window you're committing in [1]). The moment things are in the index/repository, it's pretty unlikely you're going to lose work.

Say, in other systems, me accidentally clicking something is a surefire way to just wipe it out without a second thought. In TFSVC I can easily undo my active changes with a simple click of a button. Again, the contention was that you actively lose work while working with git. It's hard to do, as deleting work in git requires some fairly specific commands.

Even removing a file requires you to stage the deletion, then commit it. And even THEN, even if you amend some other previous commit with that deletion you can role the entire thing back with reflog and get your file back. If I took that amended commit and rebased onto another branch, rolled that all into one commit via squashing, I'd still be able to go back to where I was with the reflog.

If however, you edit some lines in a file and then tell git to checkout that file again and they're not staged, then sure, you're going to lose work. But that's not something that's common and it certainly isn't a recipe for having git "actively" delete work.

[1] http://www.bitkeeper.org/man/citool.html

> If the repository is locked, and you try to bk commit, the commit will fail. You can wait for the lock to go away and then try the commit again; it should succeed. If the lock is an invalid one (left over from an old remote update), then you can switch to another window and unlock the repository. After it is unlocked, the commit should work.

If you want correctness then you lock the repo when you are updating it. We do that and make it work on NFS, which is not that easy to do.

If you want to live in a world where two people can be wacking the repo at the same time with undefined results, be my guest, you seem like that sort of person. We are not. We like atomic commits.

As for BK being expensive compared to Git, you are so right. 10 years ago. These days we do quite well and we do it correctly.

I dunno why you have a hardon to smear BK, but bring it dude, I'm happy to make you look foolish.

>I dunno why you have a hardon to smear BK, but bring it dude,

Excuse me? You brought up BitKeeper. You're the one that claimed I've never used a sane SCM, because you think BitKeeper is sane and I clearly didn't include that in my list of the World's Most Sane SCM's list. Added bonus for the claim we're all "missing out" on sanity.

Here I'll even link you to the post you made: https://news.ycombinator.com/item?id=16806588 And a screenshot https://imgur.com/a/JO8IE

>I'm happy to make you look foolish.

You're actively on this forum basically demonstrating why BitKeeper and other SCM's have lost. You bring up silly things like templated commit messages, random anecdotes that don't technically make any sense, and claim annotating/blaming history in files is hard to do in git.

>These days we do quite well and we do it correctly.

Some guy got so pissed off at your SCM and made a new for one free, without wasting untold amounts of man hours and capital. And he wasn't the only one (Mercurial). He did it so well that other companies now use his SCM as a cornerstone for their platforms (GitHub and BitBucket).

> He did it so well that other companies now use his SCM as a cornerstone for their platforms (GitHub and BitBucket).

I think this is your fundamental misunderstanding. Git would be another esoteric tool for crazy kernel devs without GitHub. Git won because of GitHub. Very simple. Out in the real world of teams of 12 developers rewriting the same business logic over and over until they retire, Git is GitHub. I've worked with several developers who don't understand the difference, and think that they're using the GitHub client whenever they interact with Git locally (and, if they use GitHub Desktop, they are). All your discussion about git's dominance being a testament to the tractability of the git UI is a false equivalence.

GitHub could switch to BitKeeper under the covers overnight, and as long as they branded it in a non-scary way, very few people would know the difference.

When is it ever the case that general acceptance means "objectively the best" instead of "obviously the path of least resistance"?

Bitbucket functionality was nearly identical to GitHub. Plus there was a bunch of other code hosting platforms, e.g. Sourceforge and Google Code.

So what's so special about GitHub if not Git? Slightly better UI?

I think network effect and the fact that the linux kernel was in git. When the kernel was using BitKeeper that was huge for us, people went "welp, if it's good enough for the kernel it's good enough for us".

And I think, might be wrong, but I think github was first.

>Git won because of GitHub

No it didn't. GitHub was built because of git's popularity. That's a really silly claim to make and doesn't even logically make sense. The tool was popular, someone built a hosted service for it.

Like think about the insanity of what you're saying. A company was built around some "esoteric" tool, despite plenty of alternatives existing at the time and you think people just whimsically invested in this company because of... what exactly?

You're literally just talking from historical ignorance and making up shit. It's so easy to verify any of the claims you decided to type out yet you chose not to anyway. GitHub believed in Git's popularity, and it paid off.

>I've worked with several developers who don't understand the difference

That's a really neat anecdotal story.

>GitHub could switch to BitKeeper under the covers overnight

No they couldn't. They couldn't even switch to it over a two year time frame. You are making absolutely ridiculous claims with nothing to back it up. BitBucket, owned by Atlassian, has hosted Mercurial repositories. Don't see anyone lining up to switch over to Mercurial.

A really easy claim that is obviously negated by a practical example and you still chose to make it? Legitimately silly.

>All your discussion about git's dominance being a testament to the tractability of the git UI is a false equivalence.

That's not even what that word means.

>When is it ever the case that general acceptance means "objectively the best" instead of "obviously the path of least resistance"?

Don't know if you were around for when git was released but there is now a whole graveyard of SCM's that people actively dropped to switch to git. And BitKeeper was definitely one of them. But I guess those were all dropped because of a future platform that no one knew about at the time. Heavy sarcasm by the way.

> Don't know if you were around for when git was released but there is now a whole graveyard of SCM's that people actively dropped to switch to git.

Indeed I was, and FWIW I distinctly remember everyone throwing their weight behind Mercurial, in large part for its superior cross-platform support.

I stand by my position. git usage would be minor without GitHub. GitHub could switch off git if they wanted to and they'd take most of the git user base with them.

I agree with cookiecaper. We went hard (for us) into marketing before giving up and what we learned by going to dev conferences is that people think GitHub is source management. If you talk about any sort of workflow other than what github provides you can just see their brain switch off.

It's sad, because there are other useful work flows, but GitHub is SCM at this point. I agree with what someone said elsewhere, they could swap out git for bitkeeper and nobody would care (well the people that are still butthurt over the licensing would whine but it's apache v2 now, that should be good enough).

>If you talk about any sort of workflow other than what github provides you can just see their brain switch off.

I'm sorry, what dev conferences are you going to? You're kind of just claiming that these same people are too stupid to understand what git allows you to do out of the box so they wouldn't mind BitKeeper's (or any other SCM like it) problems and limitations as long as GitHub hosted it for them with a nice logo (which again, isn't true because other hosted SCM's solutions lost as well). That's just incredibly tone deaf and doesn't make sense from a historical timeline perspective. This is just straight up denial at this point.

>well the people that are still butthurt over the licensing would whine but it's apache v2 now, that should be good enough

It's not just a licensing issue and you know it. You are being dishonest with everyone here and yourself. There is a historical record in the lkml archives that you're choosing to ignore.

>I distinctly remember everyone throwing their weight behind Mercurial

Except for nearly every single open source project.

>Mercurial, in large part for its superior cross-platform support.

And then that got side stepped by the obvious problems with repository size and branching issues (that hg would go onto address later).

>I stand by my position.

If you want to ignore a pretty basic historical timeline that's totally up to you.