3 ms·

The security model seems to be "terrible UX defaults that you turn to unsafe defaults instead." You end up with a lot of gotchas instead of them just working.

by jayd16 4y ago

The security model seems to be "terrible UX defaults that you turn to unsafe defaults instead." You end up with a lot of gotchas instead of them just working. The mental model of juggling multiple repos in a non-atomic way also violates the rule of least astonishment. Working with read only submodules smooths this part out at least. GUI support is slowly getting better at least.

pengaru 4y ago
> The security model seems to be "terrible UX defaults that you turn to unsafe defaults instead." Except practically nothing in git is unsafe, it's like Plan9's Venti in the sense that you can only add content to it. You never lose data, but you can easily lose your bearings. I presume a major reason why there's not much effort put into UX guard rails preventing losing one's bearings in the day-to-day work is a product of the fundamental fact that the underlying committed data is always there. People just need to at least familiarize themselves with `git reflog` to help lose the anxiety.
- layer8 4y ago
  > the underlying committed data is always there That’s not always true, due to reflog expiration and GC. This is an important difference to e.g. Subversion where you can delete branches/tags just to hide them, but the history always remains 100% there and nothing is ever really deleted.
  - SahAssar 4y ago
    In git if a commit is within the history of a branch or tag it won't be GC:ed, right?
    - layer8 4y ago
      That’s correct, but commits from that history can also be removed, for example by squashing a branch. The Git history is quite mutable in that sense and doesn’t necessarily reflect the actual commit history.
- asdfhdhadhas 4y ago
  except for that time there was a vulnerability in exactly the subsystem we're talking about. https://nvd.nist.gov/vuln/detail/cve-2018-17456 https://nvd.nist.gov/vuln/detail/cve-2018-17456 rce via recursive submodule clone ftw

by jayd16 4y ago

pengaru 4y ago

> The security model seems to be "terrible UX defaults that you turn to unsafe defaults instead." Except practically nothing in git is unsafe, it's like Plan9's Venti in the sense that you can only add content to it. You never lose data, but you can easily lose your bearings. I presume a major reason why there's not much effort put into UX guard rails preventing losing one's bearings in the day-to-day work is a product of the fundamental fact that the underlying committed data is always there. People just need to at least familiarize themselves with `git reflog` to help lose the anxiety.

layer8 4y ago
> the underlying committed data is always there That’s not always true, due to reflog expiration and GC. This is an important difference to e.g. Subversion where you can delete branches/tags just to hide them, but the history always remains 100% there and nothing is ever really deleted.
- SahAssar 4y ago
  In git if a commit is within the history of a branch or tag it won't be GC:ed, right?
  - layer8 4y ago
    That’s correct, but commits from that history can also be removed, for example by squashing a branch. The Git history is quite mutable in that sense and doesn’t necessarily reflect the actual commit history.
asdfhdhadhas 4y ago
except for that time there was a vulnerability in exactly the subsystem we're talking about. https://nvd.nist.gov/vuln/detail/cve-2018-17456 https://nvd.nist.gov/vuln/detail/cve-2018-17456 rce via recursive submodule clone ftw