>I would expect such a feature to use end-to-end encryption for the data
How would "end-to-end encryption" when such features by definition require the server to have access to the credentials to perform the required operations? If by "end to end" you actually mean it's encrypted all the way to the server, that's just "encryption in transit".
Use our new open source (modification and redistribution not permitted) app to exchange end-to-end encrypted (from your client to our server) messages with your friends! Having all your data on our service protects your data sovereignty (we do not provide for export or interop) by guaranteeing that you always have access to your full history! Usage also protects your privacy (we analyze your data for marketing purposes) by preventing unscrupulous third parties from analyzing your data for marketing purposes.
If we had competent regulators this sort of blatant willful negligence would constitute false advertising.
i think that hypothetical is too simplistic to accurately frame the situation. we're talking about one of the largest, most widely used libraries in the open source world. at that level, they don't really need unknowns to use their project to "prove themselves" - they can contribute to smaller projects or put their own work out into the world.
Git's "ours"/"theirs" terminology is often confusing to newcomers, especially when from a certain (incorrect, but fairly common) point of view their meaning may appear to be swapped between merge and rebase. I think in an attempt to make the terminology less confusing UIs tend to reinvent it, but they always fail miserably, ending up with the same problem, just with slightly different words.
This constant reinvention makes the situation even worse, because now the terminology is not only confusing, but also inconsistent across different tools.
We use SVN at work and it's a nightmare there too, "mine" and "theirs" and whatnot. I frequently end up looking at historical versions just to verify which is which.
If I have a merge conflict I typically have to be very conscious about what was done in both versions, to make sure the combination works.
I wish for "working copy" and "from commit 1234 (branch xyz)" or something informative, rather than confusing catch-all terms.
Using SmartSVN which makes life a fair bit better but still keeps this confusing terminology.
We'll be migrating to Git this year though so.
For reference, the codebase is over 20 years old, and includes binary dependencies like libraries. Makes it easy to compile old versions when needed, not so easy on the repository size...
I think even presenting them as options makes it even more confusing to newcomers. Usually I find that neither is correct and there's a change on both sides I need to manually merge (so I don't even pay attention to the terminology), but I've seen co-workers just blindly choose their changes because it's familiar looking then get confused when it doesn't work right.
I mean, if they've been regularly hitting said bug, does it matter how obscure it is? If I were using a tool that was broken for me personally, I'd be ditching it, too; with absolutely zero regard to whether the tool works for others.
> url "$my_url" parses a URL into its parts. I use this about once a month to pull data out of a URL, often because I don’t want to click a nasty tracking link.
This sounds pretty useful!
Coincidentally, I have recently learned that Daniel Stenberg et al (of cURL fame) wrote trurl[1], a libcurl-based CLI tool for URL parsing. Its `--json` option seems to yield similar results as TFA's url, if slightly less concise because of the JSON encoding. The advantage is that recent releases of common Linux distros seem to include trurl in their repos[2].
reply