>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?
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.
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.
> 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.
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"?
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.
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.
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?