4 ms·

I made this comment on a post a few days ago about using a different SCM: > I feel like an SCM would have to be WAY better than git to make it worth using. The

I made this comment on a post a few days ago about using a different SCM: > 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?

petre 4y ago
Because it gets the job done without needing to check the manual every time. We use fossil to manage most of our company code. It's stupid easy to set up, it has a web UI, it has a simple bugtracker, a wiki and a bunch of other stuff. It's fully replicated, we have backups on each repo that somebody is working with and is in sync. We don't bother with git unless we publish something on github.
- StevePerkins 4y ago
  Do you use any kind of CI/CD pipeline process at all? Pretty much every significant CI platform that I know of is Git-native, or in some cases MAY have some legacy Mercurial support. If I'm having to give up CI, or hand-roll my own pipeline system completely from scratch, then that's just an unacceptable trade-off. For a personal toy project, fine. But this seems like ridiculous bikeshedding for a professional shop in the 2020's. "Without needing to check the manual every time"? Sheesh, there are really only a few Git commands that most developers ever have to run on a regular basis anyway, and usually an IDE abstracts those.
  - Kaytaro 4y ago
    It's easy nowadays because it's popularity forced everyone to build integration. Git is a absolute nightmare to integrate with CI tools though if you actually have to develop the integration yourself. Git has no native way to reliably tell you what you actually worked on in a branch. Yes it has git diff but that is not precisely the same, and git log is A. not easy to consume B. unreliable since git has so many methods to rewrite history. If you're using something like GitHub it's obviously much easier to use their API but even that is quirky sometimes.
    - StevePerkins 4y ago
      That's my point. Most shops do NOT want to develop their on CI pipeline systems from scratch. I don't care if Fossil makes that theoretically easier, I don't want to do that at all. I want to use a Gitlab CI, or a Circle CI, or hell even a Jenkins. Git has that available ecosystem. No other serious competitor does. Theoretically, it might be easier to weave your own cloth and then tailor pants from scratch, if you use some novel synthetic fiber rather than cotton. But I don't want to weave my own cloth and tailor my own pants, so I wear cotton blue jeans.
    - thayne 4y ago
      > Git has no native way to reliably tell you what you actually worked on in a branch. Yes it has git diff but that is not precisely the same I'm not sure exactly what you mean by "what you actually worked on". If you want the files that changed a git diff between the tip of your branch and merge base of the target branch is usually sufficient. > and git log is A. not easy to consume You can customize the log format to make it easier to consume > B. unreliable since git has so many methods to rewrite history. I'm not sure what that has to do with CI/CD. But if that is somehow a problem for you, then just don't allow rewriting history. Every git server software I'm aware of supports rejecting pushes that rewrite history.
spiffytech 4y ago
> I feel like an SCM would have to be WAY better than git to make it worth using. That's how Git overthrew SVN. Cheap branching, robust conflict management, and offline workflows were killer features. Throw in Github, which is more accessible and lower friction than emailing patches and lurking on mailing lists, and SVN's fate was sealed.
- throwaway894345 4y ago
  Not only that, but it got in as programming was exploding in popularity. It didn’t need to convert people from SVN because it could focus on new users.
- williamstein 4y ago
  A really critical sneaky trick that Linus pulled in the implementation of Git was to just pretend like Sha1 hashes never collide, which helped make "cheap branching, robust conflict management, and offline workflows" possible. This (false but convenient) assumption massively reduced the complexity of many algorithms, and allowed Git to efficiently do things that other source control systems couldn't do. I personally switched from Darcs to Git about 15 years ago entirely due to performance issues.
  - adrian_b 4y ago
    The assumption that with an 160-bit hash you will not get collisions is pretty safe. I have actually searched for collisions by hashing several tens of millions of files with various hashes. With shorter hashes I have seen collisions, but even with an 128-bit good hash there were no collisions, much less with an 160-bit hash. Unless you hash many billions of things, the chances of SHA-1 collisions are negligible.
  - mongol 4y ago
    Has there ever been a hash collision happening in git by pure chance?
    - Groxx 4y ago
atombender 4y ago
My prediction, tangentially: The next evolution over Git will happen at GitHub. GitHub (and to a much lesser extent, GitLab) is really what allows Git to monopolize the VCS landscape these days, and it's been true almost from the start. GitHub was really Git's killer app; before it was popular, there was still uncertainty about whether the winner of the VCS wars would be Git, or Mercurial, or Bazaar, or whatever. GitHub was what helped Git win that war. Nobody will be able to break Git's hold over the world except GitHub itself, unless they are able to disrupt GitHub entirely. The player in the best position to do so is Microsoft. They can sneakily launch a competing version (without cannibalizing their own product) within GitHub itself, allowing repos to be selectively "upgraded" to it, and even two-way-mirrored so that Git users can continue to use it until they're ready to migrate. I think Git will relatively easy to disrupt on technological merits as we slowly (very slowly!) move away from old ways of doing things. The current development cycle where individual developers hack away at their local repo and then submit patches already seems antiquated; meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way? The other trend we see is the need for code collaboration tools to become more integrated. Git is essentially a glorified file system that happens to have good undo and diffing tools, and the workflows around building, testing, project management, etc. are comparatively primitive for what we developers actually need. For example, right now I do commits locally, then push to a branch, create a PR, and wait for it to build and run tests, then look at the failures, and go back, do some more commits, and rinse and repeat. Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes? In particular, we see tools winning over other tools when they reduce friction. I think that's where the next iteration of version control and code collaboration tools will find its way in.
- je42 4y ago
  > The other trend we see is the need for code collaboration tools to become more integrated. Visual Studio Code Live Share is a precursor for this.
- CorrectHorseBat 4y ago
  >meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way? It's bad enough for anything but some quick notes, but it sounds like a nightmare for code. >Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes? Nobody stops you from auto saving and running a build every time a files change (I actually did this for my thesis in Latex). IMO this has nothing to do with Git.
martinvonz 4y ago
If the other SCM is compatible with Git, you may not have to learn much about Git. That's my hope for my SCM: https://github.com/martinvonz/jj https://github.com/martinvonz/jj. I agree that it seems very hard for a new SCM to get many users without having good compatibility with Git.
- KajMagnus 4y ago
  I was just looking for something like Fossil/Git but that focused on a clean history :- ) jj's Automatic Rebase and rewriting history support look lovely ( https://github.com/martinvonz/jj#comprehensive-support-for-rewriting-history https://github.com/martinvonz/jj#comprehensive-support-for-r... ) and "Conflicts can be recorded in commits", e.g. for starting resolving a merge at home, continuing in the afternoon at the co-working space, a different laptop. `jj edit` and `describe` looks like things I'd use a lot. Nice with Rust and Nix (Hi Martin I'm Magnus from Gbg btw :- )) `jj st` — nice naming. I've named my scripts directory just 's', since, typing is not that fun

petre 4y ago

Because it gets the job done without needing to check the manual every time. We use fossil to manage most of our company code. It's stupid easy to set up, it has a web UI, it has a simple bugtracker, a wiki and a bunch of other stuff. It's fully replicated, we have backups on each repo that somebody is working with and is in sync. We don't bother with git unless we publish something on github.

StevePerkins 4y ago
Do you use any kind of CI/CD pipeline process at all? Pretty much every significant CI platform that I know of is Git-native, or in some cases MAY have some legacy Mercurial support. If I'm having to give up CI, or hand-roll my own pipeline system completely from scratch, then that's just an unacceptable trade-off. For a personal toy project, fine. But this seems like ridiculous bikeshedding for a professional shop in the 2020's. "Without needing to check the manual every time"? Sheesh, there are really only a few Git commands that most developers ever have to run on a regular basis anyway, and usually an IDE abstracts those.
- Kaytaro 4y ago
  It's easy nowadays because it's popularity forced everyone to build integration. Git is a absolute nightmare to integrate with CI tools though if you actually have to develop the integration yourself. Git has no native way to reliably tell you what you actually worked on in a branch. Yes it has git diff but that is not precisely the same, and git log is A. not easy to consume B. unreliable since git has so many methods to rewrite history. If you're using something like GitHub it's obviously much easier to use their API but even that is quirky sometimes.
  - StevePerkins 4y ago
    That's my point. Most shops do NOT want to develop their on CI pipeline systems from scratch. I don't care if Fossil makes that theoretically easier, I don't want to do that at all. I want to use a Gitlab CI, or a Circle CI, or hell even a Jenkins. Git has that available ecosystem. No other serious competitor does. Theoretically, it might be easier to weave your own cloth and then tailor pants from scratch, if you use some novel synthetic fiber rather than cotton. But I don't want to weave my own cloth and tailor my own pants, so I wear cotton blue jeans.
  - thayne 4y ago
    > Git has no native way to reliably tell you what you actually worked on in a branch. Yes it has git diff but that is not precisely the same I'm not sure exactly what you mean by "what you actually worked on". If you want the files that changed a git diff between the tip of your branch and merge base of the target branch is usually sufficient. > and git log is A. not easy to consume You can customize the log format to make it easier to consume > B. unreliable since git has so many methods to rewrite history. I'm not sure what that has to do with CI/CD. But if that is somehow a problem for you, then just don't allow rewriting history. Every git server software I'm aware of supports rejecting pushes that rewrite history.

spiffytech 4y ago

> I feel like an SCM would have to be WAY better than git to make it worth using. That's how Git overthrew SVN. Cheap branching, robust conflict management, and offline workflows were killer features. Throw in Github, which is more accessible and lower friction than emailing patches and lurking on mailing lists, and SVN's fate was sealed.

throwaway894345 4y ago
Not only that, but it got in as programming was exploding in popularity. It didn’t need to convert people from SVN because it could focus on new users.
williamstein 4y ago
A really critical sneaky trick that Linus pulled in the implementation of Git was to just pretend like Sha1 hashes never collide, which helped make "cheap branching, robust conflict management, and offline workflows" possible. This (false but convenient) assumption massively reduced the complexity of many algorithms, and allowed Git to efficiently do things that other source control systems couldn't do. I personally switched from Darcs to Git about 15 years ago entirely due to performance issues.
- adrian_b 4y ago
  The assumption that with an 160-bit hash you will not get collisions is pretty safe. I have actually searched for collisions by hashing several tens of millions of files with various hashes. With shorter hashes I have seen collisions, but even with an 128-bit good hash there were no collisions, much less with an 160-bit hash. Unless you hash many billions of things, the chances of SHA-1 collisions are negligible.
- mongol 4y ago
  Has there ever been a hash collision happening in git by pure chance?
  - Groxx 4y ago

atombender 4y ago

My prediction, tangentially: The next evolution over Git will happen at GitHub. GitHub (and to a much lesser extent, GitLab) is really what allows Git to monopolize the VCS landscape these days, and it's been true almost from the start. GitHub was really Git's killer app; before it was popular, there was still uncertainty about whether the winner of the VCS wars would be Git, or Mercurial, or Bazaar, or whatever. GitHub was what helped Git win that war. Nobody will be able to break Git's hold over the world except GitHub itself, unless they are able to disrupt GitHub entirely. The player in the best position to do so is Microsoft. They can sneakily launch a competing version (without cannibalizing their own product) within GitHub itself, allowing repos to be selectively "upgraded" to it, and even two-way-mirrored so that Git users can continue to use it until they're ready to migrate. I think Git will relatively easy to disrupt on technological merits as we slowly (very slowly!) move away from old ways of doing things. The current development cycle where individual developers hack away at their local repo and then submit patches already seems antiquated; meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way? The other trend we see is the need for code collaboration tools to become more integrated. Git is essentially a glorified file system that happens to have good undo and diffing tools, and the workflows around building, testing, project management, etc. are comparatively primitive for what we developers actually need. For example, right now I do commits locally, then push to a branch, create a PR, and wait for it to build and run tests, then look at the failures, and go back, do some more commits, and rinse and repeat. Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes? In particular, we see tools winning over other tools when they reduce friction. I think that's where the next iteration of version control and code collaboration tools will find its way in.

je42 4y ago
> The other trend we see is the need for code collaboration tools to become more integrated. Visual Studio Code Live Share is a precursor for this.
CorrectHorseBat 4y ago
>meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way? It's bad enough for anything but some quick notes, but it sounds like a nightmare for code. >Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes? Nobody stops you from auto saving and running a build every time a files change (I actually did this for my thesis in Latex). IMO this has nothing to do with Git.

martinvonz 4y ago

If the other SCM is compatible with Git, you may not have to learn much about Git. That's my hope for my SCM: https://github.com/martinvonz/jj https://github.com/martinvonz/jj. I agree that it seems very hard for a new SCM to get many users without having good compatibility with Git.

KajMagnus 4y ago
I was just looking for something like Fossil/Git but that focused on a clean history :- ) jj's Automatic Rebase and rewriting history support look lovely ( https://github.com/martinvonz/jj#comprehensive-support-for-rewriting-history https://github.com/martinvonz/jj#comprehensive-support-for-r... ) and "Conflicts can be recorded in commits", e.g. for starting resolving a merge at home, continuing in the afternoon at the co-working space, a different laptop. `jj edit` and `describe` looks like things I'd use a lot. Nice with Rust and Nix (Hi Martin I'm Magnus from Gbg btw :- )) `jj st` — nice naming. I've named my scripts directory just 's', since, typing is not that fun