throwaw20221107
Joined 4 years ago
Karma
45
Submissions
32
Member since
Nov 7
Recent submissions
Comment · 4 years ago
This is another argument why "not squashing is bad"; because it discourages people from committing.
Comment · 4 years ago
That's fair. Both overwrite (edit: seemingly overwrite) (un)staged changes. But `checkout` requires less hyphens.
I feel like all of this would be resolved if my boy Linus had renamed `git add` to `git stage` or `git prepare` or something more clear.
Or added some warning, like "all this stuff you haven't committed yet; it's not managed by `git` so don't try to overwrite it all using `git` until you've committed some of it."
Comment · 4 years ago
Ya this is basic economics, fixed investment vs markup driven return.
Comment · 4 years ago
>merging a sequence of PRs from same branch is bad if you squash
For me in this scenario, merging `main` w/ squash commit back into PR2 branch after PR1 gets merged works here.
As an aside — if code review is the bottleneck, it's probably not a huge investment to do some git fenangling to get the above to merge cleanly.
But I don't see how this use case is a dealbreaker or even specific to squash...? Won't you have to incorporate/merge other devs' changes to `main` back into PR2 anyhow, regardless of whether PR1 was a squash, rebase, or full history?
Comment · 4 years ago
Sure but the vision/nlp models required to enable context-sensitive vision apps (i.e. an app to "give me facts from Wikipedia about what I'm seeing"), those models are closed and owned by big companies like Google and OpenAI.
The previous two computing revolutions "personal computers" and "apps/websites" were enabled by the openness of the OS and the openness of TCP/IP and browser vendors, respectively. If the next "AR/VR" revolution depends on complex vision models, there's no guarantee they'll be open for independent devs. And judging by the last few years, it's highly likely they won't be.
BTW I think there's good reason they don't release GPT-3 or DALL-E or PaLM or whatever. That shit is dangerous.
Edit: ok you can hack the hardware to let you run the models or make the necessary network calls to run them. That's still way different than Wikipedia which is a first class webapp where you don't have to hack anything to use it.
Comment · 4 years ago
> the truly adversarial case is rare
The problem is not adversarial, or due to malice. The problem is ignorance and expediency driven by a desire to push code and little incentive to cleanup your git history.
The easy fix is to squash PRs.
The hard fix is to enforce that devs become "crafters" and to define what is and isn't "good faith".
Comment · 4 years ago
The problem is who is doing the crafting. (And the approving.) At least squash based approach limits to 1 the number of commits an untrustworthy "crafter" can occupy.
Comment · 4 years ago
"Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.”
Comment · 4 years ago
Ratorx, do we work on the same team at google? I feel like I've heard you before?
Comment · 4 years ago
Ok I agree, you roll back to the known working version. The easiest way to do that is revert the whole PR (or data deploy in case of flags, ofc). My point is not "flags vs. no flags". My point is "each PR should generate one commit because that's easy to revert".
The commit dag of git is a cool feature but shouldn't be in `main`. It's so much easier to work with a linear history and one where each commit contains all the required context to figure out "could this have broken something".
Comment · 4 years ago
Sure. I'm just talking about binary deploy. Of course you're gonna use flags to flight things in an industry context, depending on the company and its CI/CD practices.
Let's say the binary deploy (before flighting) is fucked somehow. Then what do you do?
Comment · 4 years ago
What do you mean?
Dev 1: "I would like my PR to make 2 commits into `main` instead of the 1 that everyone else gets via squash."
Dev 2: "Ok then make 2 PRs."