6 ms·

> their rationale for it reads very much along the lines of "you're holding it wrong". Keep in mind that Fossil was written specifically to support the SQLite

> their rationale for it reads very much along the lines of "you're holding it wrong". Keep in mind that Fossil was written specifically to support the SQLite team's workflow. It was never designed for _anyone_ else's needs. They don't care if it doesn't work for other people's work styles because they didn't write it for other people.

flohofwoe 4y ago
...and Git was designed specifically for the Linux kernel development workflow, I think this is a small but important detail that's lost on many people who think that Git is the only versioning system in town. A lot of other versioning systems didn't or don't allow to rewrite history either, and they're doing their job just fine.
- professoretc 4y ago
  > ...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.
  - 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.
- deleted 4y ago
  [deleted]

flohofwoe 4y ago

...and Git was designed specifically for the Linux kernel development workflow, I think this is a small but important detail that's lost on many people who think that Git is the only versioning system in town. A lot of other versioning systems didn't or don't allow to rewrite history either, and they're doing their job just fine.

professoretc 4y ago
> ...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.
- 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.
deleted 4y ago
[deleted]