6 ms·

I feel like an SCM would have to be WAY better than git to make it worth using. The entire developer community is on git, so you are still going to have to know

I feel like an SCM would have to be WAY better than git to make it worth using. The entire developer community is on git, so you are still going to have to know how to use git in order to access other open source projects. If you are already going to have to be using git for many things, why add a second SCM you have to learn to use?

JonChesterfield 4y ago
The learning curve on git is absurd. It's just so long ago we've mostly forgotten.
- SoftTalker 4y ago
  And I would speculate that most devs only know a small fraction of git's functionality. It is certainly the case for me.
  - Gigachad 4y ago
    Yeah the initial intro to git takes about 10 minutes. Git add ., git commit, git push. Done. You learn new features as they become required. There is no need to read the entire manual and understand how git bisect works when you are working on your personal blog.
    - MatthiasPortzel 4y ago
      I was thinking about this the other day. The learning curve for git isn’t steep at all, because it’s possible to learn git so slowly. It’s possible to use git with any level of proficiency. If you had to sit down and “learn git” before you could use it, that would be brutal and we would be using something else.
    - nmz 4y ago
      Love it when people don't talk about rebase. considering its both dangerous, and a requirement to use for many teams.
      - vr46 4y ago
        Rebase is the opposite of dangerous, it brings everything back to a specific state and forces the dev to fix conflicts themselves rather than make it someone else’s problem. What’s dangerous is using things one doesn’t understand and not asking how to use it or reading up on it.
      - SoftTalker 4y ago
        Yeah that's one of the ones I don't touch.
      - inferiorhuman 4y ago
        It's a lot less dangerous than you'd think since you can salvage a lot of mistakes by digging into the reflog.
      - dahart 4y ago
        Rebase isn’t dangerous in safety terms, the main danger is it can cause frustration when people use it without understanding it first. And as long as people know to not rebase public history, the frustration is usually limited and contained and easily resolved. It might be dangerous if frustration leads to spastic repo nuking, which can happen. Btw A lot of people who say rebase is dangerous use git stash and have no idea that stash is one of the actual dangerous things to do, much more dangerous than rebase, and not any easier than branching. “If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms.” https://git-scm.com/docs/git-stash https://git-scm.com/docs/git-stash
- deleted 4y ago
  [deleted]
- cortesoft 4y ago
  Right, but my point is you are STILL going to have to learn git anyway, since so many companies and open source projects use it. Your choice is not to learn git OR the other SCM, the choice is to learn just git OR git and the other SCM. You aren't saving any effort.
  - olig15 4y ago
    Not everyone uses Git, or even works with projects that use Git…
  - blumomo 4y ago
    Could you be obsessed with effort reducing? If yes, you may want to look at it like an investment: you initially spend effort, time or money to learn something new only to get back more later.
  - marginalia_nu 4y ago
    I've used git for a decade and I still haven't learned half of it. It's got to be one of the most byzantine pieces of software I have ever encountered.
- hn_throwaway_99 4y ago
  I always find this to be a weird statement, primarily because I think there are like 50 other things that are waaay more difficult when it comes to software development, but I hear people time and again say git has a big learning curve. I mean, once I understood the major concepts of git, and understood how its model was fundamentally different from something like svn or cvs, it wasn't that hard to use it. Sure, it took time to learn, but given that it's a tool so integral to my working life, I'm fine with spending a little more time learning it if it makes me more productive in the long run.
- nwatson 4y ago
  I stick to Atlassian Sourcetree git GUI for most git stuff. I drop down to git command-line for cherry-picking, squash-merging, updating a not-currently-checked-out branch, etc. Sourcetree works well with sub-repos. I use integrated kdiff3 for visual diff (when I need to go beyond Sourcetree's already-excellent diff viewing). Sourcetree's killer feature is easy staging/unstaging different "hunks" of files, or even individual selected lines. I use mostly Jetbrains IDEs, I'm sure their git/VCS integration is pretty good, but I stick to Sourcetree plus occasional command-line for most stuff. I'd probably fail a git-oriented interview section because I'd fail at the command-line for some common things for which I just use Sourcetree. In any case though with my approach I've seen I generally get a much better overview of code changes and branching strategies and have a more flexible and convenient experience that many other coworkers over the years.
  - mroche 4y ago
    I haven't used Sourcetree in several years, how's it hold up today? When I was using graphical clients I hopped between Sourcetree, GitKraken[0] and Sublime Merge[1]. [0]: https://www.gitkraken.com/ https://www.gitkraken.com/ [1]: https://www.sublimemerge.com/ https://www.sublimemerge.com/
    - inferiorhuman 4y ago
      I loved SourceTree but abandoned it as soon as Atlassian made it impossible to use offline. I don't want an Atlassian or bitbucket or whatever the fuck account. Sublime Merge is pretty good IMO, but not good enough I'd want to pay for it.
      - AnonC 4y ago
        I’ve used SourceTree maybe a month or so ago, and it was completely offline for a repo that’s not pushed to or connected with Bitbucket or Atlassian. Maybe initially there was a dialog box to create an account with or sign up for Bitbucket, but that was easily dismissed.
        4y ago
- bottled_poe 4y ago
  I certainly struggled to grok git early on, but I feel this is largely because the documentation and explanations were convoluted. I think you can grasp it quickly by just understanding a few key concepts, namely: a commit is a set of changes to files, branches/tags are basically references to a specific commit, commits have an ancestor commit, remotes track distinct copies of the graph. Then you just need to know which commit you are interested in, how to navigate the graph of commits, and how to merge deviated sets of changes. If you understand those things, you know everything you’ll need to 90% of the time.
- thayne 4y ago
  Is there a VCS that doesn't have a steep learning curve? I've used subversion, mercurial, darcs, and bazaar to varying degrees. None were particularly easy to learn.
xenophonf 4y ago
This is pretty much why I switched from Mercurial to Git, and in retrospect, it was absolutely the right decision. Not only did that choice relieve me of having to master two different version control systems, it meant I could build on top of the huge amount of Git tooling and (more importantly) training material out there. Teaching colleagues and using tools they can put on their résumés is pretty important. Iconoclasm isn't always a good way to live (or do business).
- inferiorhuman 4y ago
  heh heh. I worked at a small shop where one lone guy kept everyone on bzr until we staged a coup.
  - xenophonf 4y ago
    Yeah, I was that guy. We used Mercurial for way too long. I thought I'd learned my lesson, switched to Git, etc. Then I started rolling out SaltStack and turned myself back into that guy. I finally gave up when I realized I was the bottleneck on so many people's work. Went back to plain old written deployment guidance about three years ago. Now I'm looking at containerization and orchestration tooling and worrying if I'm making the same freaking mistake yet again. It's such a difficult balancing act, especially as one moves into management. I could, by fiat, mandate tooling (and do). But will I regret my possibly poor choice in 5 years? I don't know—let's find out!
    - inferiorhuman 4y ago
      Yeah I was that guy too at one point when we went from svn to git. bzr just bore mention because it is so lacking in third party support.
srer 4y ago
There are significant pockets of non-git users in the developer community ;) I find hg much more pleasant to use than git, and can generally still work in git based teams while using hg. I find pijul's approach much more interesting than git's, and look forward to pijul (and others :) pushing forward how we do revision control. I don't believe git to be the end of the evolution of revision control systems (which for me has looked like cp -> rcs -> cvs -> svn -> git|hg), and find git lacking enough that I look forward to what the next generation does. Would I argue that you personally should branch outside of your git centric world? Of course not! Just as I've worked with many devs who live their lives gainfully employed only knowing Java, or sys admins who only know Microsoft, it is up to you as to if you wish to explore different approaches and styles to achieve your end goal.
- cortesoft 4y ago
  Sure, their are developer communities around the other SCMs, and many are passionate about those alternatives. My point is that even if you do get into one of those other communities, you are still going to have to learn how to use git because so much of the world uses it. You will need it either for your job or because the open source project you want to use is on it. You can't skip learning git. If you don't mind that, then go for it. For me, I don't want to use my limited capacity for learning things on learning a second (or third, since I still have SVN usage somewhere in my brain) SCM.
  - olig15 4y ago
    That’s not true. I’m a gamedev and have never had to learn git. The closest would be downloading a zip from GitHub. Almost all game dev is done on Perforce due to the enormous asset sizes we work with.
    - johnny22 4y ago
      so you're saying contribute to absolutely no 3rd party code? The person is saying that if you spend time outside of your VCS bubble, then you will end up using git, even if you don't like it.
zitterbewegung 4y ago
Feature for feature Fossil is more like a competitor to Github or gitlab. Basically it is a SCM based on sqlite that is a lightweight version of those websites offer.
- cliffwarden 4y ago
  To add some detail here. The features it offers (tickets, wiki, chat, forums, etc) are stored within the repo, unlike github or gitlab where those things may be separate. Basically, if you have the repo and the fossil binary you have everything. Is this better? I never saw a lot of advantages in my style of work, but i could see this being huge for someone who has intermittent connectivity. Or maybe someone who wants to use the ticket tracking, etc without setting up a separate server or public instance. I just love that fossil exists and there is a diversity of opinion on how things can work.
jayd16 4y ago
I suppose a competitor could also have some kind of git compatibility shim built in to ease the adoption.
- monetus 4y ago
  Fossil does let you import and export git I think. Fossil just has the wiki and issues on its side
  - ElectricalUnion 4y ago
    Is this import and export loseless (at least from the git side)? From the documentation I read last time I tried something like this, it wasn't and required workflow workarounds on both sides.
2OEH8eoCRo0 4y ago
Right. Half of Git's strength is that it's ubiquitous with an unmatched community of users. Nearly every development tool is built to integrate. An scm can be better, some probably are, but it won't match these other traits.
jamal-kumar 4y ago
Fossil came out in a time when your options were basically CVS, SVN, or something commercial like Perforce. Git is an innovation that came out around 2005 (A year before Fossil), and it took a few years to get some traction, but holy moly are either of these better than what came before. It's just way easier to mess things up in the old school systems. I think it's pretty interesting in that it's a hugely replete web application written in C that does all sorts of stuff... bug tracking, wiki, etc.
cyber_kinetist 4y ago
I've heard that a large part of the game industry still uses Perforce because Git still doesn't work with binary files that well. (The game industry doesn't really have much of an open dev community compared to other places, so that kinda explains why they don't feel the urge to switch to Git.) PlasticSCM has risen in recent years as a direct competitor, but Unity has bought the company and I'm not clear what the future for it would be. If Fossil had good support for binary files I would have considered switching from Git (since Git LFS is just yuck), but from what I've heard it doesn't look too good.
- neurocline 4y ago
  It’s not binary files per se, it’s size. Checkout sizes are in the 50 GB and up range. Also, unmergeable files are common, so there’s a strong desire for exclusive checkout. This is why game teams either split source and data (awkward to impossible depending on the game), or use Perforce.

JonChesterfield 4y ago

The learning curve on git is absurd. It's just so long ago we've mostly forgotten.

SoftTalker 4y ago
And I would speculate that most devs only know a small fraction of git's functionality. It is certainly the case for me.
- Gigachad 4y ago
  Yeah the initial intro to git takes about 10 minutes. Git add ., git commit, git push. Done. You learn new features as they become required. There is no need to read the entire manual and understand how git bisect works when you are working on your personal blog.
  - MatthiasPortzel 4y ago
    I was thinking about this the other day. The learning curve for git isn’t steep at all, because it’s possible to learn git so slowly. It’s possible to use git with any level of proficiency. If you had to sit down and “learn git” before you could use it, that would be brutal and we would be using something else.
  - nmz 4y ago
    Love it when people don't talk about rebase. considering its both dangerous, and a requirement to use for many teams.
    - vr46 4y ago
      Rebase is the opposite of dangerous, it brings everything back to a specific state and forces the dev to fix conflicts themselves rather than make it someone else’s problem. What’s dangerous is using things one doesn’t understand and not asking how to use it or reading up on it.
    - SoftTalker 4y ago
      Yeah that's one of the ones I don't touch.
    - inferiorhuman 4y ago
      It's a lot less dangerous than you'd think since you can salvage a lot of mistakes by digging into the reflog.
    - dahart 4y ago
      Rebase isn’t dangerous in safety terms, the main danger is it can cause frustration when people use it without understanding it first. And as long as people know to not rebase public history, the frustration is usually limited and contained and easily resolved. It might be dangerous if frustration leads to spastic repo nuking, which can happen. Btw A lot of people who say rebase is dangerous use git stash and have no idea that stash is one of the actual dangerous things to do, much more dangerous than rebase, and not any easier than branching. “If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms.” https://git-scm.com/docs/git-stash https://git-scm.com/docs/git-stash
deleted 4y ago
[deleted]
cortesoft 4y ago
Right, but my point is you are STILL going to have to learn git anyway, since so many companies and open source projects use it. Your choice is not to learn git OR the other SCM, the choice is to learn just git OR git and the other SCM. You aren't saving any effort.
- olig15 4y ago
  Not everyone uses Git, or even works with projects that use Git…
- blumomo 4y ago
  Could you be obsessed with effort reducing? If yes, you may want to look at it like an investment: you initially spend effort, time or money to learn something new only to get back more later.
- marginalia_nu 4y ago
  I've used git for a decade and I still haven't learned half of it. It's got to be one of the most byzantine pieces of software I have ever encountered.
hn_throwaway_99 4y ago
I always find this to be a weird statement, primarily because I think there are like 50 other things that are waaay more difficult when it comes to software development, but I hear people time and again say git has a big learning curve. I mean, once I understood the major concepts of git, and understood how its model was fundamentally different from something like svn or cvs, it wasn't that hard to use it. Sure, it took time to learn, but given that it's a tool so integral to my working life, I'm fine with spending a little more time learning it if it makes me more productive in the long run.
nwatson 4y ago
I stick to Atlassian Sourcetree git GUI for most git stuff. I drop down to git command-line for cherry-picking, squash-merging, updating a not-currently-checked-out branch, etc. Sourcetree works well with sub-repos. I use integrated kdiff3 for visual diff (when I need to go beyond Sourcetree's already-excellent diff viewing). Sourcetree's killer feature is easy staging/unstaging different "hunks" of files, or even individual selected lines. I use mostly Jetbrains IDEs, I'm sure their git/VCS integration is pretty good, but I stick to Sourcetree plus occasional command-line for most stuff. I'd probably fail a git-oriented interview section because I'd fail at the command-line for some common things for which I just use Sourcetree. In any case though with my approach I've seen I generally get a much better overview of code changes and branching strategies and have a more flexible and convenient experience that many other coworkers over the years.
- mroche 4y ago
  I haven't used Sourcetree in several years, how's it hold up today? When I was using graphical clients I hopped between Sourcetree, GitKraken[0] and Sublime Merge[1]. [0]: https://www.gitkraken.com/ https://www.gitkraken.com/ [1]: https://www.sublimemerge.com/ https://www.sublimemerge.com/
  - inferiorhuman 4y ago
    I loved SourceTree but abandoned it as soon as Atlassian made it impossible to use offline. I don't want an Atlassian or bitbucket or whatever the fuck account. Sublime Merge is pretty good IMO, but not good enough I'd want to pay for it.
    - AnonC 4y ago
      I’ve used SourceTree maybe a month or so ago, and it was completely offline for a repo that’s not pushed to or connected with Bitbucket or Atlassian. Maybe initially there was a dialog box to create an account with or sign up for Bitbucket, but that was easily dismissed.
      - 4y ago
bottled_poe 4y ago
I certainly struggled to grok git early on, but I feel this is largely because the documentation and explanations were convoluted. I think you can grasp it quickly by just understanding a few key concepts, namely: a commit is a set of changes to files, branches/tags are basically references to a specific commit, commits have an ancestor commit, remotes track distinct copies of the graph. Then you just need to know which commit you are interested in, how to navigate the graph of commits, and how to merge deviated sets of changes. If you understand those things, you know everything you’ll need to 90% of the time.
thayne 4y ago
Is there a VCS that doesn't have a steep learning curve? I've used subversion, mercurial, darcs, and bazaar to varying degrees. None were particularly easy to learn.

xenophonf 4y ago

This is pretty much why I switched from Mercurial to Git, and in retrospect, it was absolutely the right decision. Not only did that choice relieve me of having to master two different version control systems, it meant I could build on top of the huge amount of Git tooling and (more importantly) training material out there. Teaching colleagues and using tools they can put on their résumés is pretty important. Iconoclasm isn't always a good way to live (or do business).

inferiorhuman 4y ago
heh heh. I worked at a small shop where one lone guy kept everyone on bzr until we staged a coup.
- xenophonf 4y ago
  Yeah, I was that guy. We used Mercurial for way too long. I thought I'd learned my lesson, switched to Git, etc. Then I started rolling out SaltStack and turned myself back into that guy. I finally gave up when I realized I was the bottleneck on so many people's work. Went back to plain old written deployment guidance about three years ago. Now I'm looking at containerization and orchestration tooling and worrying if I'm making the same freaking mistake yet again. It's such a difficult balancing act, especially as one moves into management. I could, by fiat, mandate tooling (and do). But will I regret my possibly poor choice in 5 years? I don't know—let's find out!
  - inferiorhuman 4y ago
    Yeah I was that guy too at one point when we went from svn to git. bzr just bore mention because it is so lacking in third party support.

srer 4y ago

There are significant pockets of non-git users in the developer community ;) I find hg much more pleasant to use than git, and can generally still work in git based teams while using hg. I find pijul's approach much more interesting than git's, and look forward to pijul (and others :) pushing forward how we do revision control. I don't believe git to be the end of the evolution of revision control systems (which for me has looked like cp -> rcs -> cvs -> svn -> git|hg), and find git lacking enough that I look forward to what the next generation does. Would I argue that you personally should branch outside of your git centric world? Of course not! Just as I've worked with many devs who live their lives gainfully employed only knowing Java, or sys admins who only know Microsoft, it is up to you as to if you wish to explore different approaches and styles to achieve your end goal.

cortesoft 4y ago
Sure, their are developer communities around the other SCMs, and many are passionate about those alternatives. My point is that even if you do get into one of those other communities, you are still going to have to learn how to use git because so much of the world uses it. You will need it either for your job or because the open source project you want to use is on it. You can't skip learning git. If you don't mind that, then go for it. For me, I don't want to use my limited capacity for learning things on learning a second (or third, since I still have SVN usage somewhere in my brain) SCM.
- olig15 4y ago
  That’s not true. I’m a gamedev and have never had to learn git. The closest would be downloading a zip from GitHub. Almost all game dev is done on Perforce due to the enormous asset sizes we work with.
  - johnny22 4y ago
    so you're saying contribute to absolutely no 3rd party code? The person is saying that if you spend time outside of your VCS bubble, then you will end up using git, even if you don't like it.

zitterbewegung 4y ago

Feature for feature Fossil is more like a competitor to Github or gitlab. Basically it is a SCM based on sqlite that is a lightweight version of those websites offer.

cliffwarden 4y ago
To add some detail here. The features it offers (tickets, wiki, chat, forums, etc) are stored within the repo, unlike github or gitlab where those things may be separate. Basically, if you have the repo and the fossil binary you have everything. Is this better? I never saw a lot of advantages in my style of work, but i could see this being huge for someone who has intermittent connectivity. Or maybe someone who wants to use the ticket tracking, etc without setting up a separate server or public instance. I just love that fossil exists and there is a diversity of opinion on how things can work.

jayd16 4y ago

I suppose a competitor could also have some kind of git compatibility shim built in to ease the adoption.

monetus 4y ago
Fossil does let you import and export git I think. Fossil just has the wiki and issues on its side
- ElectricalUnion 4y ago
  Is this import and export loseless (at least from the git side)? From the documentation I read last time I tried something like this, it wasn't and required workflow workarounds on both sides.

2OEH8eoCRo0 4y ago

Right. Half of Git's strength is that it's ubiquitous with an unmatched community of users. Nearly every development tool is built to integrate. An scm can be better, some probably are, but it won't match these other traits.

jamal-kumar 4y ago

Fossil came out in a time when your options were basically CVS, SVN, or something commercial like Perforce. Git is an innovation that came out around 2005 (A year before Fossil), and it took a few years to get some traction, but holy moly are either of these better than what came before. It's just way easier to mess things up in the old school systems. I think it's pretty interesting in that it's a hugely replete web application written in C that does all sorts of stuff... bug tracking, wiki, etc.

cyber_kinetist 4y ago

I've heard that a large part of the game industry still uses Perforce because Git still doesn't work with binary files that well. (The game industry doesn't really have much of an open dev community compared to other places, so that kinda explains why they don't feel the urge to switch to Git.) PlasticSCM has risen in recent years as a direct competitor, but Unity has bought the company and I'm not clear what the future for it would be. If Fossil had good support for binary files I would have considered switching from Git (since Git LFS is just yuck), but from what I've heard it doesn't look too good.

neurocline 4y ago
It’s not binary files per se, it’s size. Checkout sizes are in the 50 GB and up range. Also, unmergeable files are common, so there’s a strong desire for exclusive checkout. This is why game teams either split source and data (awkward to impossible depending on the game), or use Perforce.