The interface is still bad. Teaching people to use git is still obnoxious because it's arcane. It's like 1e AD&D. It does everything it might need to, but it feels like every aspect of it is bespoke.
It's also relatively difficult to make certain corrections. Did you ever accidentally commit something that contains a secret that can't be in the repository? Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else.
It's also taken over 10 years to address the SHA-1 limitation, and it's still not complete. It's a little astonishing that it was written so focused on SHA-1 never being a problem that it's taken this long to keep the same basic design and just allow a different hashing algorithm.
I'm not a git expert but I cant image that's true
> generate a new key
Is absolutely the right answer. If you pushed a key, you should treat it as already compromised and rotate it.
No it doesn't. Git is buggy. It also doesn't work for anything that's not a text file. It is unbelievably slow.
You can define a custom git merge driver to teach git how to handle your proprietary format.
Edit: after a quick google search I found the following curated list, https://github.com/jelmer/awesome-merge-drivers
Citation needed on this one. Every problem I've ever seen arise with git came from someone not understanding the model or not knowing all the commands. Those don't make it better, but they don't mean it's buggy either.
What do I need to do on top of a git force push, and some well documented remote reflog/gc cleanup, which I can’t find with a single search/LLM request? Are we there, where we don’t have enough developers who can do this without feeling it as a burden? Or are we there where this level of basic logic is not needed to implement anything production ready?
This is a self-defeating argument. You're essentially saying we shouldn't improve something because it can be done with a handful of commands (you already know btw) and prompting an LLM.
> Are we there, where we don’t have enough developers who can do this without feeling it as a burden?
The no true scotman.
> Or are we there where this level of basic logic is not needed to implement anything production ready?
Not sure how this fits in with the rest honestly.
It was never about whether it was possible. It was about how it's being done. Juniors (and even seniors) accidentally check in secrets. Arguing that there shouldn't be a simpler way to remove an enormous security flaw feels a bit disingenuous.
gitcli != git
> It was never about whether it was possible. It was about how it's being done.
That's what I was saying originally, no need to change the infrastructure but you can change how you interact with it.
> Arguing that there shouldn't be a simpler way to remove an enormous security flaw feels a bit disingenuous.
First of all, skill issue educate your employees. Secondly, this is a well considered and a huge part of why git is preferred over older systems like SVN or SCCS especially in an open source context where you are distributing your code through unknown channels and where the publisher might have moved on.
Perhaps Git is not the best VCS for your situation. But I think that if you try other options you will run into bigger problems, there is a reason git became the standard in the industry.
[0] https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3... [1] https://git-scm.com/book/en/v2/Getting-Started-The-Command-L...
If you're entire argument rests on people being perfect, it's a trash argument.
Implying that accidents don't happen when you have skills is absurd.
Btw, I’m also saying that who cannot find how it can be solved right now with git, those shouldn’t be allowed anywhere near a repo with write permission, no matter whether you use git or not. At least until now, this level of minimal logical skill was a requirement to be able to code. And btw regardless the tool, the flow will be the exact same: ask a search engine or ml model, and run those. The flow is like this for decades at this point. So those minimal logical skills will be needed anyway.
The problem mainly is that when they don’t even know that they shouldn’t push secrets. You won’t be able to help this either any tooling. At least not on git level.
That's not what a strawman is.
> Also you answered to me in an authoritative way, when even according to you, you don’t understand my comment.
No, I didn't understand what referring to production-ready code has anything to do with making mistakes in source control.
> And also of course a nice fallacy fallacy.
You keep using words you don't understand.
> The problem mainly is that when they don’t even know that they shouldn’t push secrets. You won’t be able to help this either any tooling. At least not on git level.
You're not actually suggesting you become immune to making mistake after a certain level of experience, are you? That would be insane.
This is not the problem they are redesigning for, they are redesigning the infrastructure. Github is a live example of a different interface on top of git and that is working fine (though some may have their complaints with it), no redesign of git's underlying "infrastructure" needed.
> Did you ever accidentally commit something that contains a secret that can't be in the repository?
This is an inconvenience for secrets (have become more commonplace since the creation of git) but by my understanding this was a very deliberate choice in the design of git. It grantees integrity in the distributed source. For example you can check the hash of the last commit en be sure that your mirror did not inject malicious code.