EDIT: I have no tab management issues either, and my workflow is quite similar to what’s described above. But I’ve seen many people who have different needs.
I’ve never tried any of the Chi-Fi brands so I’m not saying this to favor them but: my Apple AirPods Pro have had issues too - uneven battery usage so one earpiece would discharge before the other, and hissing during quiet passages. Tried them for a week or two and then returned them.
Hissing most likely comes from media, unequal discharge rate is legit problem. I'm not an apple fan but when it comes to reliability major brands at least do some product design and quality checks, meanwhile most chi-fi IEMs have options for MMCX connectors that are entirely unsuitable for the use case and should have been shot down during the design phase, but hey - "the more options the better".
P.S. For anyone thinking i bash just because of China or western audiophile superiority - no i just got burned by articles like this and crinnancle reviews twice and sharing my experience.
Not when there is no media playing. This was back when the first Pros came out and when I googled it, there were a lot of reports of the same issue.
I say all this as a generally-happy Apple product consumer btw - and of course, there are many people who don’t experience these issues. But that goes for the Chi-Fi brands as well, since we’re ultimately talking about quality control.
Also in Sweden. Most people, almost everyone, have their phone numbers and addresses listed in publicly searchable databases. Everyone's taxable income is public too (accessing it online costs a nominal fee from an aggregator service).
It's fine, it's not really abused that much. You can request a protected identity from the authorities if you really do have stalkers but it's a bureaucratic hassle. Mainly since everything in this society relies on anyone wanting to do business with you to be able to look your existence up using your personal number.
I was responding to the reference in GP’s comment that “…your name, address, and phone number would published…” which is the case with gulesider. Their comment was about pre-internet, mine was referring to the post-internet version. Apologies if there was confusion.
Additionally, the Wikipedia page on ‘Telephone directory’ [0] states:
> A telephone directory, commonly called a telephone book, telephone address book, phonebook, or the white and yellow pages
I don't think I'm splitting hairs here. The difference is that your name isn't in "gule sider", since it's a directory of businesses.
"Telefonkatalogen" was what other countries call "white pages", which is a directory of individuals.
The GP comment was indeed about the pre-Internet, but the whole point is that nobody publishes a big, widely distributed book with everyone's names in it anymore. You could literally get a book with every living adult in Norway listed. Sure, you have online services like 1881.no and gulesider.no that are the successors to this directory, but they're not at all the same thing.
> The difference is that your name isn't in "gule sider", since it's a directory of businesses.
I must be missing something; I can find pretty much every person I know in Norway in there by looking up their name (unless they have explicitly opted out).
Not the GP but we tend to use decently small and meaningful commits to make PRs easier to review. They then get squashed, so you can only (easily) revert the whole PR.
Personally I’m happy with that. If the thing merged caused an issue, I’d want to revert the entire thing that was merged, not a subpart of it which would result in a state of the codebase that nobody reviewed.
If you’re very diligent about making good atomic commits that always pass all test that can work, but I find that squashing PRs (and PRs being relatively small) is a very good trade off
Sounds reasonable. Also, when squashing a PR would conflate unrelated commits then maybe those commits should have been separate PRs instead.
I've recently started to like squashing after usually preferring rebase merges, because with squashes I have an easy option to rewrite the commit message and edit out all of those meaningless "fix typo", "improve" and "now actually working" lines...
> I've recently started to like squashing after usually preferring rebase merges, because with squashes I have an easy option to rewrite the commit message
And why couldn't you rewrite the commit messages while rebasing?
EDIT: oh, you mean from the GitHub webUI, I presume. Got it.
> EDIT: oh, you mean from the GitHub webUI, I presume. Got it.
Yes, exactly, while reviewing and merging other peoples PRs. Technically I could still rewrite in other ways, but while squashing in the web UI was the most comfortable workflow.
You're not the only ones, but I can't understand this approach. Do people never then read the version history? It must be impossible to understand commits' diffs with the changes all squashed together.
Not the OP, but I think that the point of squashing every PR is that the reviewers/PR run the whole PR, not the individual commits. If you have a PR with 5 commits, 4 of which break the build and the last one fixes it, then merging that will be a problem if you need to git bisect later.
So the idea is really "what's the point of having a history full of broken state?".
> It must be impossible to understand commits' diffs with the changes all squashed together.
This would be a hint that your PR was too big and addressing more than one thing.
> So the idea is really "what's the point of having a history full of broken state?".
I rebase commits so they don't break the build but the history remains clean and incremental. Selective fixups and so on isn't the same as squashing everything into a single commit.
> This would be a hint that your PR was too big and addressing more than one thing.
I don't think so. Sure, that can be true, but squashes can also simply lose vital history. Suppose you remove a file and then replace it with code copied and modified from another file. If you then squash that, all Git will say is you made a massive edit to the file.
> I rebase commits so they don't break the build but the history remains clean and incremental.
Sure, and that's fine. The idea of the squash workflow is that they don't expect that. It's just different, and that's the rationale behind it :-).
> all Git will say is you made a massive edit to the file.
Which IMO is exactly what happened in this case xD. But again... whatever floats your boat, I was just talking from the point of view of a squash workflow.
> If you have a PR with 5 commits, 4 of which break the build and the last one fixes it, then merging that will be a problem if you need to git bisect later.
And the answer is that you don't; each commit is individually testable and reviewable. Changes requested by reviewers are squashed into the commits and then merged into the project. Unfortunately, while the git command line has "range-diff" to ease review with this workflow, neither GitHub not Gitlab have an equivalent in their UI.
Well, I was obviously meaning that "workflows that squash the commits in a PR are workflows where each individual commit is not tested/reviewed separately".
Of course, if your workflow is different, then... well it is different. Doesn't make the "squash workflows" irrational.
> And the answer is that you don't; each commit is individually testable and reviewable.
How does this work in practice? Is every single atomic commit reviewed by someone? When do they review each of those commits? How many commits typically go into a PR?
> Changes requested by reviewers are squashed into the commits and then merged into the project.
So a reviewer finds the appropriate commit that their comment applies to, and then changes the actual commit itself? Who is the author of the commit at that point?
I'm trying to understand what you're talking about, because you seem to have something figured out, for a problem that every team I've worked on struggles with.
> Is every single atomic commit reviewed by someone? When do they review each of those commits? How many commits typically go into a PR?
1) yes 2) when a PR is submitted 3) it can be a lot for a huge project-wide refactoring, but generally I would say 1 to 5 is typical and up to 20 is not strange.
> So a reviewer finds the appropriate commit that their comment applies to, and then changes the actual commit itself?
No, the author applies the requested change and force-pushes once he has gotten all the requested changes applied.
> because you seem to have something figured out
Thanks! But it's not me—it's how Linux has used git from the beginning, for example. In fact it's the only workflow that is used by projects that still use email instead of GitHub/Gitlab PRs, but (trading some old pain with new pain) it is possible to use it even with the latter. The harder part is marching the review comments to the new patch, which is actually pretty easy to do with emails.
It's quite some work and there's some learning curve. But depending on the project it can be invaluable when debugging. It depends a lot on how much the code can be covered by tests, in particular.
I can only conclude that people who think squashing a work item into a single commit is great have never had to do serious bug hunting, relying on commit history for context, nor have they ever moved forges and lost the context from "the context is in the PR anyway".
I think I've done all those things except forges. I don't know what that one is. I still like squashing. I've wven become the git expert on my team. With squashed PR resolutions, I can more reliably use bisect. Many individual commits were never actually meaningful in the first place.
I think it's a bit of a limited conclusion. Maybe they really just make small PRs that make sense, and maybe they rewrite the commit message into something useful when squashing.
My employer has all PRs merged by a bot once they're approved. The bot takes the PR description and uses that as the commit message. The PR is the unit of change that gets reviewed, not the commit. This makes for a nice linear bisectable history of commits (one per PR) with descriptions, references to issues on our tracker, etc. And no need to worry about force pushing, rebasing, etc, unless you want to do so.
Of course it's got the same end result as doing an interactive rebase & combining all the in-progress commits into a single reviewable unit of change with a good commit message, but it's a bit more automatic.
While Obsidian may not be FOSS at all, my understanding is that in general needing to purchase a license is orthogonal to whether something is FOSS - correct?
If you cannot use the software however you wish (including for profit) then it is not Free Software. The developers can choose to not distribute the software to you unless you pay, and they can choose to provide support if you pay (which if you're making a profit from their software is a reasonable thing to pay for), but with Free Software the developers cannot decide how you use it once they have distributed it to you.
However, this becomes less significant when the applications are interoperable. If you ever stop using Obsidian, you can just grab your files and use another Markdown editor on top.
