You are confusing the initial construction with the long-term ownership. Most of the time, the corporation that builds the apartment block will sell the apartments, not continue to own them and rent them out.
The developer and property owner are (usually) still different people in this case. Owning and constructing a rental property have very different risk profiles so the same people don't want to be in that business.
> The developer and property owner are (usually) still different people in this case.
I would say the general contractor might be different, but the developer and property owner and always the same where I live for tall apartment blocks with 100% rentals.
Even if this is true, this is a distinction without a difference. If a developer can't sell their property to someone else, there's a good chance they wouldn't build it in the first place. If they do decide to never sell their apartment complex, they won't have the liquidity required to build another.
Yes. To figure out what happened, and which path it took to get into my repo. Or to see how branches have diverged.
I also recommend it to git newbies, as a tool to understand the state of their repo when something has gone wrong (e.g. they did a bad merge or rebase).
People often bring up this objection, but I don't want a complete history—I want an easy-to-understand history.
If I make a variable in commit A and think of a better name for it in commit C, why wouldn't I use rebase to squash C into A? Some sense of purity of history?
Or more directly related to the rebase vs. merge debate, if I fix an issue across three functions, and in the meantime someone has removed one of those functions on the main branch, rebasing eliminates the "history" of me fixing that removed function and I think that's good. It makes my commit simpler.
Rebase can certainly be used to simplify the history too much, but that will always be a judgement call. That shouldn't keep us from editing our branches in ways that are clarifying instead of confusing.
We never capture the full complexity of what we went through writing code in our source control. It would be bad if we did.
I think a lot of people are anti rebase in general, but doing that on your own is fine IMO. I have a different issue.
The issue with is with rebasing multiple commits onto master instead of merging - the intermediate commits were never code that anyone ever actually wrote or tested, so any issues with them stem purely from the fakeness of the history.
If you have commit A then you write a branch A -> B -> C while someone else writes A -> D and they merge first, rebasing to get A -> D -> B' -> C' means B' was never something you wrote or tested. This code never existed on anyone's machine or had CI run on it before the rebase.
Does it really make sense to run CI on all of the new intermediate commits that rebase invented? What if some of those fail, are you really going to go through and fix tests for fake intermediate commits?
The solution for me has always been to squash. Inventing fake history is totally pointless and counterproductive. If you want cleanliness and bisectability via destroying the "real" history, just go ahead and really destroy it, don't invent a fake, possibly broken history.
I think the Rust project strikes a pretty good compromise for this issue: rebased linear branches with conflict-free merges onto master. When you make a PR, the CI sees whether your branch can be merged onto master without causing a conflict; if not, it directs you to rebase your branch onto the latest version of master. This check is repeated for all open PRs whenever the master branch is updated.
Once it's satisfied that your branch can be merged, it runs a subset of the tests, and throws an error if they fail. This way, even if you do rebase your branch, its latest commit will still be tested. (Having intermediate commits pass tests is encouraged but not required.) Finally, it regularly takes groups of 8 or so accepted PRs, tries merging them all in sequence, and runs the full test suite on the result. If it succeeds, the merge commits are pushed to master; if not, a human operator gets it to try again without the offending PR.
By your terminology, I suppose this would count as running CI on all the "invented" commits, and forcing PR authors to fix all their tests. But in practice, it's not too odious, since most PRs don't conflict (unless you're touching half the codebase), and any test failures from a non-conflicting change will get caught by the merge step.
An easy to understand history that is correct about the relevant details... but "David didn't happen to run the formatter before his WIP commit that time" isn't ever going to be a relevant detail.
That is fine. No-one in 5 years cares that a dev did 10 “fix test”, “ci format”, “fix misc derp”. Changes should be single units, such that bisect works cleanly to find the resulting bugs.
I've been using git for ~15 years and I've also never looked at it visually, except by accident. And yes, this does include working on big repos with lots of other people. Maybe we're the weird ones.
Same reason anyone visualises any data. It makes it easier and quicker to understand (unless it is a mess due to not rebasing & too fine commit granularity).
While you're right that it's usually jazz kissas, the Sasebo bar[1] I mentioned had instruments for live playing - sort of like a mini-studio. Apparently some patrons might play rock there sometimes. But yes, I assume it was mostly about listening to recorded music.
The owner said that young people were leaving Sasebo for bigger cities with more work, so that was draining the vitality of the area. A common story all over Japan, as you probably know.
I've also been to jazz clubs in Japan and those are cool, but clearly a dying breed given the ages of the audience and most of the musicians. At a matinee at the historic Shinjuku Pit Inn, I think I was among the youngest members of the audience. Similar story at smaller, more intimate spots. It's just a declining trend with long-time regulars and not much new blood.
It’s interesting how many people wrongly assumed that a Japanese jazz bar (jazz kissa) with recorded music was the same as a Western smoky jazz bar with live music.
Assumption is such a weirdly human anti-pattern.
1. It’s surprising we as humans don’t walk right into a Lemmings like disaster and massacre ourselves.
2. I highly doubt that HN is more or less enlightened but I do wonder if HN is more or less likely to have dissenting, informative, fact checking voices compared to let’s say a boar hunting forum
Mildly interesting that they are basically all self-help books. On that entire first page, I can only see one fiction book (about sixty down) - and of course, it is a comic book!
There are already white-label dating-site providers out there. Most of the "specialised" sites (e.g. uniform-wearers, "professionals") are running on them.
Radio 4's 'Feedback' [1] bills itself as "The programme that holds the BBC to account on behalf of the radio audience" and frequently interviews BBC employees.
Obviously there are fraught incentives from them paying for their own criticism. Not sure cancelling the program would improve the situation though.
