4 ms·

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

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.

kadenshep 9y ago
>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 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.
- luckydude 9y ago
  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.
  - kadenshep 9y ago
    >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 https://news.ycombinator.com/item?id=16806588 And a screenshot https://imgur.com/a/JO8IE 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).
    - cookiecaper 8y ago
      > 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"?

kadenshep 9y ago

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

luckydude 9y ago
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.
- kadenshep 9y ago
  >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 https://news.ycombinator.com/item?id=16806588 And a screenshot https://imgur.com/a/JO8IE 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).
  - cookiecaper 8y ago
    > 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"?