5 ms·

> To me it's not clear what the problem is that would require a redesign. The interface is still bad. Teaching people to use git is still obnoxious because it'

> To me it's not clear what the problem is that would require a redesign. 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.

redsocksfan45 6mo ago
[dead]
chipsrafferty 6mo ago
> 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. I'm not a git expert but I cant image that's true
- _3u10 6mo ago
  It’s not you just need to force push or generate a new key…
  - chipsrafferty 6mo ago
    Yeah it doesn't seem hard to rewrite the commit history
  - dgellow 6mo ago
    You also need to clear the caches of the remote
  - Cpoll 6mo ago
    Perhaps proving the point here. That's not enough to eliminate the secret, the dangling commit will persist. Though this might be a nitpick, it's rather hard to get it from the remote without knowing the SHA. > generate a new key Is absolutely the right answer. If you pushed a key, you should treat it as already compromised and rotate it.
- dh2022 6mo ago
  Of course is not true - look into git filter branch. I had to use it once when a developer checked in a whole bunch of binaries and created a PR which ended being merged. I had to rewrite the history and delete the files from history - just deleting the files would not suffice because the file were in git history and we’re taking too m&ch space.
gtowey 6mo ago
The interface can be independent of the implementation. Under the hood git does everything you need. If learning to use it at a low level isnt appealing, then you can put an interface on top which is more ergonomic.
- morgoo 6mo ago
  I'm a huge fan of lazygit
- bmitc 6mo ago
  > Under the hood git does everything you need No it doesn't. Git is buggy. It also doesn't work for anything that's not a text file. It is unbelievably slow.
  - foobarchu 6mo ago
    > Git is buggy 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.
  - trashb 6mo ago
    > It also doesn't work for anything that's not a text file. 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 https://github.com/jelmer/awesome-merge-drivers
    - bmitc 6mo ago
      Git still doesn't work well with non-text data, including being incredibly slow. There's a reason why game studios use things like Plastic SCM and Perforce.
      - trashb 6mo ago
        There may be situations where the git defaults aren't ideal. I found that for the special scenario of game development git-lfs did the job quite well for me. > Git still doesn't work well with non-text data Seems like you are either mishandling git in your situation or you require another tool (different merge driver or difftool?). But I would argue that in either case git infrastructure is not "Buggy" as you suggest neither does it need a rewrite like the original article suggests. It works as intended and additionally it provides you with the hooks and possibilities to adapt it to your workflow, for example handling large binary format files. Perhaps for your usecase you would be better off using an alternative for example: one drive business, Plastic SCM, Perforce, google drive or an internal file server. That doesn't mean that git should be rewritten to fit your needs. It feels like you want a regular sedan to both race in F1 and carry the same load as a lorry, use a specialized tool for your needs.
ruszki 6mo ago
> Did you ever accidentally commit something that contains a secret that can't be in the repository? 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?
- mexicocitinluez 6mo ago
  > 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? 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.
  - ruszki 6mo ago
    No, I’m saying that you can do this without replacing git. You can make it simpler even without replacing git. Aka you just did a strawman, if you are really into these. Also you answered to me in an authoritative way, when even according to you, you don’t understand my comment. You can figure out a logical fallacy name for this. And also of course a nice fallacy fallacy. 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.
danny_codes 6mo ago
git rebase -i <one commit before your mistake> git push origin mainline -f
- danielbln 6mo ago
  git log --all --reflog -- path/to/secret-file
  - dh2022 6mo ago
    Git filter rule
trashb 6mo ago
> The interface is still bad. 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.

redsocksfan45 6mo ago

[dead]

chipsrafferty 6mo ago

> 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. I'm not a git expert but I cant image that's true

_3u10 6mo ago
It’s not you just need to force push or generate a new key…
- chipsrafferty 6mo ago
  Yeah it doesn't seem hard to rewrite the commit history
- dgellow 6mo ago
  You also need to clear the caches of the remote
- Cpoll 6mo ago
  Perhaps proving the point here. That's not enough to eliminate the secret, the dangling commit will persist. Though this might be a nitpick, it's rather hard to get it from the remote without knowing the SHA. > generate a new key Is absolutely the right answer. If you pushed a key, you should treat it as already compromised and rotate it.
dh2022 6mo ago
Of course is not true - look into git filter branch. I had to use it once when a developer checked in a whole bunch of binaries and created a PR which ended being merged. I had to rewrite the history and delete the files from history - just deleting the files would not suffice because the file were in git history and we’re taking too m&ch space.

gtowey 6mo ago

The interface can be independent of the implementation. Under the hood git does everything you need. If learning to use it at a low level isnt appealing, then you can put an interface on top which is more ergonomic.

morgoo 6mo ago
I'm a huge fan of lazygit
bmitc 6mo ago
> Under the hood git does everything you need No it doesn't. Git is buggy. It also doesn't work for anything that's not a text file. It is unbelievably slow.
- foobarchu 6mo ago
  > Git is buggy 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.
- trashb 6mo ago
  > It also doesn't work for anything that's not a text file. 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 https://github.com/jelmer/awesome-merge-drivers
  - bmitc 6mo ago
    Git still doesn't work well with non-text data, including being incredibly slow. There's a reason why game studios use things like Plastic SCM and Perforce.
    - trashb 6mo ago
      There may be situations where the git defaults aren't ideal. I found that for the special scenario of game development git-lfs did the job quite well for me. > Git still doesn't work well with non-text data Seems like you are either mishandling git in your situation or you require another tool (different merge driver or difftool?). But I would argue that in either case git infrastructure is not "Buggy" as you suggest neither does it need a rewrite like the original article suggests. It works as intended and additionally it provides you with the hooks and possibilities to adapt it to your workflow, for example handling large binary format files. Perhaps for your usecase you would be better off using an alternative for example: one drive business, Plastic SCM, Perforce, google drive or an internal file server. That doesn't mean that git should be rewritten to fit your needs. It feels like you want a regular sedan to both race in F1 and carry the same load as a lorry, use a specialized tool for your needs.

ruszki 6mo ago

> Did you ever accidentally commit something that contains a secret that can't be in the repository? 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?

mexicocitinluez 6mo ago
> 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? 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.
- ruszki 6mo ago
  No, I’m saying that you can do this without replacing git. You can make it simpler even without replacing git. Aka you just did a strawman, if you are really into these. Also you answered to me in an authoritative way, when even according to you, you don’t understand my comment. You can figure out a logical fallacy name for this. And also of course a nice fallacy fallacy. 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.

danny_codes 6mo ago

git rebase -i <one commit before your mistake> git push origin mainline -f

danielbln 6mo ago
git log --all --reflog -- path/to/secret-file
- dh2022 6mo ago
  Git filter rule

trashb 6mo ago

> The interface is still bad. 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.