so there's an unconditionally correct answer (it's also equal to abs(x) for x>0), and then there is an answer that is only correct for half the domain, which requires an additional assumption.
You are talking about spatial safety. There are a few other types of memory safety:
- temporal safety (e.g. no use after free)
- initialization safety (no read of initialized memory)
- thread safety (no data races)
- type safety (accessing memory with the correct type)
> The main things that drives me crazy about jj is that all changes are always staged implicitly.
That's one way to look at it, but I would encourage you to think about it a bit differently.
JJ does not have a concept of "staging", it only has changes and commits. Yes, it automatically snapshots the workspace commit, but I wouldn't use the workspace commit as your staging area. If you want to do explicit staging use the parent commit (@-) as your staging area. You can move changes from the workspace commit (@) to the staging area (@-) explicitly, just like in Git. And you can "commit" (Git terminology) your staging area by starting a new staging area.
The difference here really is "only" that the workspace, the index, and committed changes are modeled with the same concept. And that is very powerful. Admittedly you have to make an informed decision on how to map your workflows onto the model, but that is what comes with the powerful flexibility that it gives you.
The CDU has moved from very right to less right, but still right-of-center under Merkel. After Merkel they have moved back right, maybe even more than they were to compete with the extremists.
You can still use a similar workflow as with the index. The difference is that the staging area is modeled as a commit, so it's not another concept that will take a while to grok.
> Sapling supports cloning, pushing, and pulling from a remote Git repo. jj also does, and it also supports sharing a working copy with a Git repo, so you can use jj and git interchangeably in the same repo
As a minor update - sapling now also supports the .git on-disk formats so that you can use git and sl interchangeably in the same repo
reply