> 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?
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.
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.
Which doesn't mean it's currently risky, I'm not sure how you'd turn a collision into an attack without leaning on external systems (like code review that approves by SHA, and allows you to push later). But if MD5's history is any clue, that will not be true in the long run.
The time to begin moving to a new algorithm was several years ago, when those collisions were demonstrated. Git is unambiguously lagging behind basic security practices here, though that's likely currently fine. The question is for how long that will remain true, and that's something that can only be answered after it has already become unsafe.
Or if I'm wrong about the timestamp being part of the computed checksum: add a space to your commit message. Very simple.
The malicious failure modes... I don't know. No doubt something is possible, particularly when you account for common surrounding-system usage patterns.
As an infosec engineer, this is a bit disingenuous. From a statistical perspective, you can pretty much assume that it's impossible to create colliding SHA-1 hashes.
In the intervening years we've discovered security flaws in SHA-1 that allow attackers to create collisions under certain circumstances. That's not great, and now we have ways to migrate repositories to SHA-256 hashes (although it's not yet the default).
But this decision wasn't "sneaky". Cryptographers everywhere routinely build systems under the assumption that hash collisions can't happen, because that's an explicit design goal of hash functions. If we ever find a way that this doesn't hold true, the answer isn't to design the system around the possibility of a collision, it's to switch to a better hash.
How long is it going to take Git to follow?
What is the exact scenario in which a hash collision would be dangerous? (Like, you give some random person push access to your repository and... I'm really getting lost here... they override some commit with a different commit with the same hash? And that's somehow worse than them just creating a new commit with a different hash, which you would notice for sure? And the only reason you won't notice their Evil Change is because they sneaked it in inside a hash collision?)
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.
Visual Studio Code Live Share is a precursor for this.
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.
As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality.
It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be.
That's a job for the testsuite then, I don't want my version control system to require language specific knowledge. It is also a very hard problem if you want to do it 100% correct. Impossible I would say.
>It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be.
I really don't understand how that could work or why you even want it in the first place. It sounds like a nightmare to me. I want to be able to make some local changes, stage them, maybe commit and rebase and finally review and push. For very simple documents live editing works great, but for bigger ones it sucks. I would love to see documents move to the git workflow. Imagine a Word document or an Excel table with an automatically generated version history table from commits, that would be great.
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.
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.
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.
jj's Automatic Rebase and rewriting history support look lovely ( 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