6 ms·

See, you're trying to foist a position on me that isn't mine—that I'm scared of the essential necessities of source control. And you act as if source control w

See, you're trying to foist a position on me that isn't mine—that I'm scared of the essential necessities of source control. And you act as if source control were invented with Git. Neither of these are true. > git/hg Mercurial was a great solution to the same problem that Git set out to tackle, virtually free of Git's foibles. The tradeoff was a few minor foibles of its own, but a much better tool. It's a fucking shame that Git managed to suck all the air out of the room, and we're left with a far, far worse industry standard.

kadenshep 8y ago
>you're trying to foist a position on me that isn't mine I just said you can't give specifics on what to change, because there isn't much too change. >And you act as if source control were invented with Git No I'm not? >and we're left with a far, far worse industry standard. Yeah, we definitely should have gone with the system that can't do partial checkouts correctly or even roll things back. Branching name conflicts across remote repositories and bookmark fun! Git won for a reason, because it's good and sane at what it does.
- pjmlp 8y ago
  That reason was called Linus and Linux kernel development. The master can do no wrong.
  - AstralStorm 8y ago
    No, the reason is mercurial sucked at performance with many commits at the time, and was extra slow when merging. Lacked a few dubious features such as merging multiple branches at the same time too. It has improved but git is still noticeably more efficient with large repositories. (Almost straight comparison is any operation on Firefox repository vs its git port.)
    - pjmlp 8y ago
      Mercurial has always been better than Git on Windows. Those dubious features are so relevant to daily work that I didn't even knew they existed.
      - AstralStorm 8y ago
        Git main target is Linux. Obviously. Performance on the truly secondary platform was not relevant and it is mostly caused by slow lstat call. Instead Mercurial uses additional cache file which instead is slower on Linux with big repos. But happens to be faster in Windows. And the octopus merge is used by kernel maintainers sometimes if not quite a lot. That feature is impossible to add in Mercurial as it does not allow more than two commit parents.
        pjmlp 8y ago
        Which reinforces the position that git should have stayed a Linux kernel specific DVCS, as the Bitkeeper replacement it is, instead of forcing its use cases on the rest of us.
        kadenshep 8y ago
        >Which reinforces the position that git should have stayed a Linux kernel specific DVCS No it doesn't? People use octopus merges all the time, every single day.
        pjmlp 8y ago
        Well, I only get blank stares when I mention octopus merges around here.
        btschaegg 8y ago
        ...as I get stares (okay, mostly of fear) if I point out that we need a branch in my workplace. What you can/can't do (sanely) with your tool shapes how you think about its problem space. To emphasize that even more: Try to explain the concept of an ML-style sum type (i.e. a discriminated union in F#) to someone who only knows languages with C++-based type systems. You'll have a hard time to even explain why this is a good idea, because they will try to map it to the features they know (i.e. enums and/or inheritance hierarchies), and fail to get the upsides.
Grue3 8y ago
>Mercurial was a great solution to the same problem that Git set out to tackle, virtually free of Git's foibles. No, Mercurial's design is fundamentally inferior to Git, and practically the entire history of Mercurial development is trying to catch up to what Git did right from the start. For example having ridiculous "permanent" branches -> somebody makes "bookmarks" plugin to imitate Git's lightweight branches -> now there are two ways to branch, which is confusing. No way to stash -> somebody writes a shelve plugin -> need to enable plugin for this basic functionality instead of being proper part of VCS. Editing local history is hard -> Mercurial Queues plugin -> it's still hard -> now I think they have something like "phases". In Git all of this was easy from the start. Another simple thing. How to get the commit id of the current revision. Let's search stack overflow: https://stackoverflow.com/questions/2485651/print-current-mercurial-revision-hash https://stackoverflow.com/questions/2485651/print-current-me... The top answer is `hg id -i`. $ hg id -i adc56745e928 The problem is, this answer is wrong! This simple command can execute for hours on a large enough repository, and requires write privileges to the repository! Moreover, it returns only a part of the hash. There's literally no option to display the full hash. The "correct" answer is `hg parent --template '{node}'`. Except `hg parent` is apparently deprecated, so the actual correct way is some `hg log` invocation with a lot of arguments.
- baud147258 8y ago
  I would not call "hg log -r tip" a lot of arguments. Also, on the git/hg debate, I feel I've had problems (like the stash your modification and redownload everything) more often with git that hg. I mean perhaps it tells something about my capability to understand a directed acyclic graph, but hg seems less brittle when I'm using it.
- renox 8y ago
  I disagree with some of your comments, is git stash really essential or unneeded complexity? That's debatable, I never use it personally. What I don't like in git is the loss of history associated with squashing commits, I would prefer having a 'summary' that would keep the full history but by default would ne used like a single commit.
  - 8y ago

kadenshep 8y ago

>you're trying to foist a position on me that isn't mine I just said you can't give specifics on what to change, because there isn't much too change. >And you act as if source control were invented with Git No I'm not? >and we're left with a far, far worse industry standard. Yeah, we definitely should have gone with the system that can't do partial checkouts correctly or even roll things back. Branching name conflicts across remote repositories and bookmark fun! Git won for a reason, because it's good and sane at what it does.

pjmlp 8y ago
That reason was called Linus and Linux kernel development. The master can do no wrong.
- AstralStorm 8y ago
  No, the reason is mercurial sucked at performance with many commits at the time, and was extra slow when merging. Lacked a few dubious features such as merging multiple branches at the same time too. It has improved but git is still noticeably more efficient with large repositories. (Almost straight comparison is any operation on Firefox repository vs its git port.)
  - pjmlp 8y ago
    Mercurial has always been better than Git on Windows. Those dubious features are so relevant to daily work that I didn't even knew they existed.
    - AstralStorm 8y ago
      Git main target is Linux. Obviously. Performance on the truly secondary platform was not relevant and it is mostly caused by slow lstat call. Instead Mercurial uses additional cache file which instead is slower on Linux with big repos. But happens to be faster in Windows. And the octopus merge is used by kernel maintainers sometimes if not quite a lot. That feature is impossible to add in Mercurial as it does not allow more than two commit parents.
      - pjmlp 8y ago
        Which reinforces the position that git should have stayed a Linux kernel specific DVCS, as the Bitkeeper replacement it is, instead of forcing its use cases on the rest of us.
        kadenshep 8y ago
        >Which reinforces the position that git should have stayed a Linux kernel specific DVCS No it doesn't? People use octopus merges all the time, every single day.
        pjmlp 8y ago
        Well, I only get blank stares when I mention octopus merges around here.
        btschaegg 8y ago
        ...as I get stares (okay, mostly of fear) if I point out that we need a branch in my workplace. What you can/can't do (sanely) with your tool shapes how you think about its problem space. To emphasize that even more: Try to explain the concept of an ML-style sum type (i.e. a discriminated union in F#) to someone who only knows languages with C++-based type systems. You'll have a hard time to even explain why this is a good idea, because they will try to map it to the features they know (i.e. enums and/or inheritance hierarchies), and fail to get the upsides.

Grue3 8y ago

>Mercurial was a great solution to the same problem that Git set out to tackle, virtually free of Git's foibles. No, Mercurial's design is fundamentally inferior to Git, and practically the entire history of Mercurial development is trying to catch up to what Git did right from the start. For example having ridiculous "permanent" branches -> somebody makes "bookmarks" plugin to imitate Git's lightweight branches -> now there are two ways to branch, which is confusing. No way to stash -> somebody writes a shelve plugin -> need to enable plugin for this basic functionality instead of being proper part of VCS. Editing local history is hard -> Mercurial Queues plugin -> it's still hard -> now I think they have something like "phases". In Git all of this was easy from the start. Another simple thing. How to get the commit id of the current revision. Let's search stack overflow: https://stackoverflow.com/questions/2485651/print-current-mercurial-revision-hash https://stackoverflow.com/questions/2485651/print-current-me... The top answer is `hg id -i`. $ hg id -i adc56745e928 The problem is, this answer is wrong! This simple command can execute for hours on a large enough repository, and requires write privileges to the repository! Moreover, it returns only a part of the hash. There's literally no option to display the full hash. The "correct" answer is `hg parent --template '{node}'`. Except `hg parent` is apparently deprecated, so the actual correct way is some `hg log` invocation with a lot of arguments.

baud147258 8y ago
I would not call "hg log -r tip" a lot of arguments. Also, on the git/hg debate, I feel I've had problems (like the stash your modification and redownload everything) more often with git that hg. I mean perhaps it tells something about my capability to understand a directed acyclic graph, but hg seems less brittle when I'm using it.
renox 8y ago
I disagree with some of your comments, is git stash really essential or unneeded complexity? That's debatable, I never use it personally. What I don't like in git is the loss of history associated with squashing commits, I would prefer having a 'summary' that would keep the full history but by default would ne used like a single commit.
- 8y ago