I clone it in my local work-space, and make a few commits over the course of a few days. So my local is A B C
During this time other changes have been merged into upstream, so upstream looks like A D E
I now have two options. I can try to merge from upstream or rebase off of upstream. Merging introduces a messy commit history that quickly becomes difficult to follow. Rebasing removes my local commits, applies the changes in upstream, and then re-applies my local commits.
So after rebasing my local is A D E B C. There are no messy merge commits. And ideally, I can squash my local changes into a single feature commit, so upstream ends up incredibly tidy.
At no place in this process is there any dishonesty or lying. I haven't changed the history upstream, which is the source of truth. What's the issue here?
No, your local is now A D E B' C'. Commits aren't just a diff between two tree snapshots, they are tree snapshots.
Hopefully you test and sanity check C' before submitting for review, but it's very unlikely that you're going to give B' the same treatment, making it more difficult for people to understand the history in the future (as well as breaking `git bisect`).
And even if you do, are your coworkers going to? Consistently? No CI tool that I'm aware of will enforce this for you.
> There are no messy merge commits.
No, but the underlying messy workflow is still there. You've just swept it under the rug for the sake of aesthetics, at the cost of future comprehension.
> At no place in this process is there any dishonesty or lying. I haven't changed the history upstream, which is the source of truth. What's the issue here?
Those are completely orthogonal concerns. You're presenting a false version of the repository state.
The common mantra of "don't rewrite public history" is about not creating a mess of duplicate commits, it doesn't imply that rewriting history is fine as long as it's not public.
The problem is a lot of people are already dying because of the current system. If you are in that situation, the downsides of revolution aren't really relevant.
The media in general hypes up Tesla way more than any other automaker. Like every Tesla crash makes headlines. Name any other automaker that faces the same scrutiny.
Musk has pursued an strategy that's built around very aggressive PR. This gives him lower marketing cost and lower cost of capital, so it's a reasonable approach. But he has to take the bad with the good. That includes critical articles as well as the many fawning ones.
> Name any other automaker that faces the same scrutiny.
Name any other automaker that makes claims like these about their automatic cruise control: "the person in the driver’s seat is only there for legal reasons. He is not doing anything. The car is driving itself."[1]
Did you read my comment? Tesla didn't claim that they can get there faster, Tesla claimed that their automatic cruise control doesn't require a driver at all.
Again, here is what Tesla claimed:
> "the person in the driver’s seat is only there for legal reasons. He is not doing anything. The car is driving itself."
Ford has never made a claim that spurious and dangerous like Tesla has.
Media coverage of Tesla didn't meaningfully change from the days before self-driving craze, when they were only building an electric car and sticking to facts in their marketing. They had to fight the strongly negative bias of the press since the get go; it's only recently that they started to give the press the rope on which to hang them.
I think it's maybe more likely a result of car sales being down in general. Nisan light vehicle sales are down 7.8% (~35,000 vehicles) when comparing the first 4 months of 2018 to the first 4 months of 2019.
Some tech companies kinda do it by paying employees in stock. The highest paid employee at Amazon only makes $150,000 cash, while the company creates shares of stock to fund the rest of their compensation. Those are actual shares that get taxes as income, not options.
Since Amazon doesn't participate in stock buy-backs, like most tech companies do, most of the salaries are actually funded by stock holders in the dilution of their shares.
Is that really the case? Let's say Amazon paid all salaries in cash. Also, for simplicity let's says employees view cash and stock compensation as perfect substitutes. Then the addition compensation has to be funded by Amazon - if it won't do so from cash from operations or debt, it has to come from raising equity: Which in effect is the same as paying employees in stock.
The math seemed pretty compelling. Even $100/month invested in index funds returns several hundred thousand after a few decades (or the typical working career.)
Should you ONLY skip daily lattes but living beyond your means otherwise? Of course not! But it's just one of many places to start making changes in your life towards the things that really matter to you.
The point being made is that if all that is stopping you from financial ruin is a $5 coffee a few times a week, you're pretty much already in financial ruin. The coffee really isn't and shouldn't be the thing making the difference.
Say upstream is at A.
I clone it in my local work-space, and make a few commits over the course of a few days. So my local is A B C
During this time other changes have been merged into upstream, so upstream looks like A D E
I now have two options. I can try to merge from upstream or rebase off of upstream. Merging introduces a messy commit history that quickly becomes difficult to follow. Rebasing removes my local commits, applies the changes in upstream, and then re-applies my local commits.
So after rebasing my local is A D E B C. There are no messy merge commits. And ideally, I can squash my local changes into a single feature commit, so upstream ends up incredibly tidy.
At no place in this process is there any dishonesty or lying. I haven't changed the history upstream, which is the source of truth. What's the issue here?