5 ms·

> ...and Git was designed specifically for the Linux kernel development workflow Yep. One thing I like to ask is, does your project have millions of lines of c

> ...and Git was designed specifically for the Linux kernel development workflow Yep. One thing I like to ask is, does your project have millions of lines of code, being worked on by thousands of developers scattered around the globe? If not, you might want to think about whether Git is really the best fit for your needs.

kdtsh 4y ago
What other VCS has the same tooling, free-as-in-free-beer online services, and broad base of surface knowledge as git? When I started studying my TAs brought out a cool new tool called Mercurial which was my introduction to version control. Guess how often I’ve used it since. Git is the software equivalent of the piano: easy enough to wield but difficult to master, mechanically simple but highly intricate, standardised in many different shapes and sizes with incredible variation, and truly ubiquitous. Apart from its ubiquitousness, these are all neutral features: there are lots of crappy piano players out there who might be better off learning a different instrument, but if you don’t have any other preference it’s hard to go wrong with the default choice. Git is one of those tools where it’s really not worth the trouble looking elsewhere unless you know what you’re looking for, because there’s value sometimes in going with the flow. Whether it was for the best that git was the tool we all settled on, I think there’s some good in the fact that we settled on something.
- dgfitz 4y ago
  Mercurial
  - brianwawok 4y ago
    Which has 90% the same features as git, with 10% of the tooling and knowhow around it. It legit may be a few % better for a few workflows, but why die on that hill?
    - kasey_junk 4y ago
      Sigh
      - brianwawok 4y ago
        Are you still trying to use HG? How goes that fight :)
        kasey_junk 4y ago
        Gave up. But not a day goes by I don’t get annoyed with git.
        brianwawok 4y ago
        Weird. I use it 20x a day for years, and haven't even been slightly annoyed in the last 5? years since I learned all the syntax.
    - dgfitz 4y ago
      It’s a better tool. Never seen someone complain about how to use mercurial. Complaints about how to use git are ubiquitous.
      - brianwawok 4y ago
        I used both, and I would complain about HG.
        dgfitz 4y ago
        Complain “about” it sure. Complain about how hard it is to use? I wouldn’t believe you.
  - arinlen 4y ago
    > Mercurial Is that the same Mercurial that didn't even supported stashing local changes? Exactly what does anyone stand to gain by switching from Git ti Mercurial?
    - masukomi 4y ago
      been a while since i used it but best i recall Mercurially was a very close competitor to git, but in many cases had arguably better commands for accomplishing the tasks. That is to say, less memorization of archaic patterns and more "oh that makes sense". Git has gotten a lot better in this area since then. Git stash however, is one place where it's just crap. `git stash apply stash@{3}` ?!?!? No. omg no. Sure, for "hey it works" but not for "hey let's have this be the standard interface that we give to everyone and never improve" After all these years we still can't say `git stash apply 3` ??? really? also git stash is wildly divergent in terms of conventions relative to all the other commands.
    - kasey_junk 4y ago
      Shelve shipped with mercurial 2.8 in 2013. Prior to that there were several third party extensions that did similar. But it’s a good example of why mercurial was better. It’s more ergonomic. All of the parameters on shelve match what you’d see on other hg commands and to shelve and unshelve you use those commands, not pop and push. You can also give short names to shelves for use in the ui, not just the message or sha.
      - arinlen 4y ago
        > Shelve shipped with mercurial 2.8 in 2013. Not really. Mercuria's shelve extension existed for a while but it only saw its way into Mercurial Core and made available by default with the release of Mercurial 5.1. https://www.mercurial-scm.org/wiki/ShelveExtension https://www.mercurial-scm.org/wiki/ShelveExtension I feel it's disingenuous to clam that a feature was provided by an application if it's only provided as an add-on that requires the user to explicitly enable.
        kasey_junk 4y ago
- gnubison 4y ago
  Well, it takes like 10 seconds to learn Subversion to a usable level. So you could argue that it is a superior system … everywhere it’s viable.
  - kdtsh 4y ago
    What’s the GitHub of Subversion?
    - tpoacher 4y ago
      This is the wrong question. The right question is why did git need github in the first place (while svn didn't)
      - halostatue 4y ago
        svn had forges (sourceforge, rubyforge, etc.) that fulfilled many of the same things that GitHub does.
    - rcv 4y ago
      Well... it's actually Github: https://docs.github.com/en/get-started/importing-your-projects-to-github/working-with-subversion-on-github/support-for-subversion-clients https://docs.github.com/en/get-started/importing-your-projec...
      - kdtsh 4y ago
        I mean, GitHub supports svn clients but it’s git all the way down. Granted I haven’t used svn on GitHub but I doubt it’s treated as a first class citizen. This is really just a stepping stone to migrating your VCS to git.
deleted 4y ago
[deleted]
jen20 4y ago
Regardless of whether Git is the absolute best fit (personally I’d rather use BitKeeper), the ecosystem and tooling around git makes it the best choice for almost everything.
giobox 4y ago
I'm not sure you can have this conversation in many medium to large sized organizations anymore. We retired our last SVN, Mercurial and Perforce repo years ago and migrated them to git; there is a new generation of software engineer in the industry who often literally has only ever known git. Rightly or wrongly, git has overwhelmingly won out in the VCS space for now. I also agree "distributed VCS" like git may be more complexity than many teams need. I can't remember the last time I worked on a repo offline (arguably the signature feature of distributed VCS), ever, although I can understand how this can be hugely helpful for some teams.
rcoveson 4y ago
You could say the same thing about UNIX, and yet here we are. Sometimes decent software accidentally becomes a ridiculously broad standard. You can't resist that force by dismissing it as what it was originally meant for. It doesn't matter if git is the best fit. ~Nobody under the age of thirty is picking between git anything else any more than they're picking between Linux and anything else to run their single node/java/postgres process on their prod servers.
jayd16 4y ago
You're completely ignoring the massive adoption and extension of git by the industry. Its not like git is still developed in service to kernel dev exclusively.
arinlen 4y ago
> One thing I like to ask is, does your project have millions of lines of code, being worked on by thousands of developers scattered around the globe? If not, you might want to think about whether Git is really the best fit for your needs. This personal assertion makes no sense. What leads you to assume that just because an application scales beautifully that automatically means it doesn't fit your needs? I mean, you don't even bother trying to argue feature X is disappointing or feature Y is missing. Your whole point is that git scales so if you don't need scale then... Then what? The truth of the matter is that Git works fantastically well both with personal static website projects with a dozen files and with million loc behemoths, whether in local repo only or with multiple remote repositories.

kdtsh 4y ago

What other VCS has the same tooling, free-as-in-free-beer online services, and broad base of surface knowledge as git? When I started studying my TAs brought out a cool new tool called Mercurial which was my introduction to version control. Guess how often I’ve used it since. Git is the software equivalent of the piano: easy enough to wield but difficult to master, mechanically simple but highly intricate, standardised in many different shapes and sizes with incredible variation, and truly ubiquitous. Apart from its ubiquitousness, these are all neutral features: there are lots of crappy piano players out there who might be better off learning a different instrument, but if you don’t have any other preference it’s hard to go wrong with the default choice. Git is one of those tools where it’s really not worth the trouble looking elsewhere unless you know what you’re looking for, because there’s value sometimes in going with the flow. Whether it was for the best that git was the tool we all settled on, I think there’s some good in the fact that we settled on something.

dgfitz 4y ago
Mercurial
- brianwawok 4y ago
  Which has 90% the same features as git, with 10% of the tooling and knowhow around it. It legit may be a few % better for a few workflows, but why die on that hill?
  - kasey_junk 4y ago
    Sigh
    - brianwawok 4y ago
      Are you still trying to use HG? How goes that fight :)
      - kasey_junk 4y ago
        Gave up. But not a day goes by I don’t get annoyed with git.
        brianwawok 4y ago
        Weird. I use it 20x a day for years, and haven't even been slightly annoyed in the last 5? years since I learned all the syntax.
  - dgfitz 4y ago
    It’s a better tool. Never seen someone complain about how to use mercurial. Complaints about how to use git are ubiquitous.
    - brianwawok 4y ago
      I used both, and I would complain about HG.
      - dgfitz 4y ago
        Complain “about” it sure. Complain about how hard it is to use? I wouldn’t believe you.
- arinlen 4y ago
  > Mercurial Is that the same Mercurial that didn't even supported stashing local changes? Exactly what does anyone stand to gain by switching from Git ti Mercurial?
  - masukomi 4y ago
    been a while since i used it but best i recall Mercurially was a very close competitor to git, but in many cases had arguably better commands for accomplishing the tasks. That is to say, less memorization of archaic patterns and more "oh that makes sense". Git has gotten a lot better in this area since then. Git stash however, is one place where it's just crap. `git stash apply stash@{3}` ?!?!? No. omg no. Sure, for "hey it works" but not for "hey let's have this be the standard interface that we give to everyone and never improve" After all these years we still can't say `git stash apply 3` ??? really? also git stash is wildly divergent in terms of conventions relative to all the other commands.
  - kasey_junk 4y ago
    Shelve shipped with mercurial 2.8 in 2013. Prior to that there were several third party extensions that did similar. But it’s a good example of why mercurial was better. It’s more ergonomic. All of the parameters on shelve match what you’d see on other hg commands and to shelve and unshelve you use those commands, not pop and push. You can also give short names to shelves for use in the ui, not just the message or sha.
    - arinlen 4y ago
      > Shelve shipped with mercurial 2.8 in 2013. Not really. Mercuria's shelve extension existed for a while but it only saw its way into Mercurial Core and made available by default with the release of Mercurial 5.1. https://www.mercurial-scm.org/wiki/ShelveExtension https://www.mercurial-scm.org/wiki/ShelveExtension I feel it's disingenuous to clam that a feature was provided by an application if it's only provided as an add-on that requires the user to explicitly enable.
      - kasey_junk 4y ago
gnubison 4y ago
Well, it takes like 10 seconds to learn Subversion to a usable level. So you could argue that it is a superior system … everywhere it’s viable.
- kdtsh 4y ago
  What’s the GitHub of Subversion?
  - tpoacher 4y ago
    This is the wrong question. The right question is why did git need github in the first place (while svn didn't)
    - halostatue 4y ago
      svn had forges (sourceforge, rubyforge, etc.) that fulfilled many of the same things that GitHub does.
  - rcv 4y ago
    Well... it's actually Github: https://docs.github.com/en/get-started/importing-your-projects-to-github/working-with-subversion-on-github/support-for-subversion-clients https://docs.github.com/en/get-started/importing-your-projec...
    - kdtsh 4y ago
      I mean, GitHub supports svn clients but it’s git all the way down. Granted I haven’t used svn on GitHub but I doubt it’s treated as a first class citizen. This is really just a stepping stone to migrating your VCS to git.

deleted 4y ago

[deleted]

jen20 4y ago

Regardless of whether Git is the absolute best fit (personally I’d rather use BitKeeper), the ecosystem and tooling around git makes it the best choice for almost everything.

giobox 4y ago

I'm not sure you can have this conversation in many medium to large sized organizations anymore. We retired our last SVN, Mercurial and Perforce repo years ago and migrated them to git; there is a new generation of software engineer in the industry who often literally has only ever known git. Rightly or wrongly, git has overwhelmingly won out in the VCS space for now. I also agree "distributed VCS" like git may be more complexity than many teams need. I can't remember the last time I worked on a repo offline (arguably the signature feature of distributed VCS), ever, although I can understand how this can be hugely helpful for some teams.

rcoveson 4y ago

You could say the same thing about UNIX, and yet here we are. Sometimes decent software accidentally becomes a ridiculously broad standard. You can't resist that force by dismissing it as what it was originally meant for. It doesn't matter if git is the best fit. ~Nobody under the age of thirty is picking between git anything else any more than they're picking between Linux and anything else to run their single node/java/postgres process on their prod servers.

jayd16 4y ago

You're completely ignoring the massive adoption and extension of git by the industry. Its not like git is still developed in service to kernel dev exclusively.

arinlen 4y ago

> One thing I like to ask is, does your project have millions of lines of code, being worked on by thousands of developers scattered around the globe? If not, you might want to think about whether Git is really the best fit for your needs. This personal assertion makes no sense. What leads you to assume that just because an application scales beautifully that automatically means it doesn't fit your needs? I mean, you don't even bother trying to argue feature X is disappointing or feature Y is missing. Your whole point is that git scales so if you don't need scale then... Then what? The truth of the matter is that Git works fantastically well both with personal static website projects with a dozen files and with million loc behemoths, whether in local repo only or with multiple remote repositories.