This creates an empty commit that merges all 3 branches, you can think of this as your staging area.
When you want to move specific changes to an existing commit, let's say a commit with an ID that starts with `zyx` (all jj commands highlights the starting characters that make the commit / change unambiguous):
jj squash -i --to zyx
Then select your changes in the TUI. `-i` stands for interactive.
If you want to move changes to a new commit on one of the branches:
jj split -i -A branch1
Then select the changes you want moved. `-A` is the same as `--insert-after`, it inserts the commit between that commit and any children (including the merge commit you're on).
There's one thing that's a bit annoying, the commit is there but the head of the branch hasn't been moved, you have to move it manually (I used + to get the child to be clearer, but I usually just type the first characters of the new change id):
- You state that Sponsored “Privacy-Focused Direct Results” were added to address bar, but 1. it's direct results in general, with some being sponsored and 2. it hasn't been released: https://blog.mozilla.org/en/firefox/better-search-suggestion.... The pref defaults to false in current stable.
- Yes, Anonym is an ad metrics firm, but you missed that it's focused on privacy. I am unsure whether they are actually able to achieve privacy or if it's just privacy-washing, but that's their stated goal. https://www.mozilla.org/en-US/anonym/
I don't really understand the point you're trying to make, I don't see anywhere in the post nor the title claiming the purpose changed and the title is directly related to the content. In fact, it seems like you are just agreeing with the post.
I think people can get frustrated at CI when it fails, so they're explaining that that's the whole purpose of it and why it's is a actually good thing.
I would personally actually frame it slightly different than the author. Non-flaky CI errors: your code failed CI. Flaky CI errors: CI failed. Just to be clear, that's more precise but would never catch on because people would simplify "your code failed CI" to "CI failed" over time, but I don't thing that changes it from being an interesting way to frame.
Even if the false-positive rate is very small (e.g. 0.01%), you probably won't be affected, but more than a hundred thousand of websites would be and that would still be an issue. I have no idea how big is the false-positive rate.
There are many of reports of the same happening to other sites, some of the top ones (you can find many more by searching HN for "google safe browsing"):
Are you saying that the author engaging in online activism and presenting very common criticisms of SUVs in a sarcastic way somehow implies they're bad neighbors?
I'd argue it's more like "looking at your keys while you're picking them". Selecting text is also known as highlighting and some people highlight text while reading / thinking.
You don't need primary selection to avoid the keyboard, you can also hold right-click on your selection and release it on "copy" (or right-click on your selection then left-click on copy, more intuitive but slightly more cumbersome)
I agree it's less convenient (there's an extra step: explicitly copying the text), but in my experience it's also more reliable as you don't lose it by just selecting anything.
I mostly agree, but a generalized attack at the remaining GitHub workers by calling them "losers" and then "rookies" is unwarranted and leaves a bad taste IMO.
Edit: 1. just to be clear, it's very good that they have accepted the feedback and removed that part, but there's no apology (as far as I know) and it still makes you wonder about the culture. On the other side, people make mistakes under stress. 2. /s/not warranted/unwarranted/
A structural engineer will not sign off on bad designs no matter how much pressure the company applies to them. They will resign and/or report the incident to their local regulator as a safety issue.
We don't have that for developers. Maybe shame/offense is our next best bet. You are free to work for a terrible company accepting and/or encouraging terrible design decisions, but you need to take into account the potential of being laughed at for said decisions.
I think you are correct, but you probably misunderstood the parent.
My understanding of what they meant by "retroactively apply a restrictive license" is to apply a restrictive license to previous commits that were already distributed using a FOSS license (the FOSS part being implied by the new license being "restrictive" and because these discussions are usually around license changes for previously FOSS projects such as Terraform).
As allowing redistribution under at least the same license is usually a requirement for a license to be considered FOSS, you can't really change the license of an existing version as anyone who has acquired the version under the previous license can still redistribute it under the same terms.
Edit: s/commit/version/, added "under the same terms" at the end, add that the new license being "restrictive" contributes to the implication that the previous license was FOSS
It's probable that licenses that explicitly allows revocation at will would not be approved by OSI or the FSF.
Copyright law is also a complex matter which differs by country and I am not a lawyer so take this with a grain of salt, but there seem to be "edge cases" where the license can be revoked as seen in the stackexchange page below.
When you want to move specific changes to an existing commit, let's say a commit with an ID that starts with `zyx` (all jj commands highlights the starting characters that make the commit / change unambiguous):
Then select your changes in the TUI. `-i` stands for interactive.If you want to move changes to a new commit on one of the branches:
Then select the changes you want moved. `-A` is the same as `--insert-after`, it inserts the commit between that commit and any children (including the merge commit you're on).There's one thing that's a bit annoying, the commit is there but the head of the branch hasn't been moved, you have to move it manually (I used + to get the child to be clearer, but I usually just type the first characters of the new change id):
reply