HTML4 + CSS (2?) + JavaScript is already huge platform, very much not trivial to implement. Like you can already do something like that with niche browsers like links, but it's obviously not working, so something else is needed...
Gerrit introduces the concept of Commit-Id; essentially a uuid ties to the first review which merged a proposed commit into the trunk.
Cherry picks preserve that Commit-Id. And so do rebases; because they're just text in a commit message.
So you can track history of patches that way, if you needed to. Which you won't.
(PS some team at google didn't understand git or their true requirements, so they wasted SWE-decades at that point on some rebasing bullshit; I was at least able to help them make it slightly less bad and prevent other teams from copying it)
But that Commit-Id footer has no functional effect. I don't see how it would help me if I have a clone of the repo, and my upstream (in this case, the debian maintainer) rebases.
> Which you won't.
Why not? Doesn't it make sense to be able to track the history of what patches have been applied for a debian package?
You need additional tooling to make use of Commit-Id. With Gerrit, it does link them all together.
> Doesn't it make sense to be able to track the history of what patches have been applied for a debian package?
... no. Each patch has a purpose, which will be described in the commit message. Hopefully it does what it says it does, which you can compare with its current diff.
If it was upstreamed with minimal changes, then the diff is near-empty. Drop it.
If it was upstreamed with significant changes, then the diff will be highly redundant. Drop it.
If the diff appears to do what the commit message says it does, then it probably does what it says.
If the diff is empty, either it was upstreamed or you fucked up rebasing. Don't be negligent when rebasing.
> As for the second bankruptcy, the main result of that was that their customers ended up paying the bill for other customers whose houses were destroyed.
There's half of the major problems. If I walked around covered in gasoline every day and eventually walked past someone smoking, not a lot of people would blame the smoker for me getting engulfed in flames.
Yet build a wood house in a forest maintained for thousands of years by American Indians with fire, require universal electricity supply, and suddenly it's not the homeowner's fault at all. Everyone else should bail them out over and over again.
Also rebasing has less information available to it, so it's less likely to update cleanly than merging. Don't do it!! Just consider the diff between the new head and upstream as "the diff" and describe the reasons for it.
What, no. In a merge you have two parents and their histories. In a rebase you have... the same thing as-if you had merged a fast-forward-ready branch. It's the same thing.
If you insist you can add Merge commits to bracket fast-forward pushes, but arguably there is no need, and especially so for something like Debian packages where the convention would be that Debian's patches are "always on top", so you can see them by doing `git log ${base}..${debian_release_branch}` for any release. (And what's the base? Whatever upstream branch/tag the Debian release is based on, but you can add more tags with a Debian naming convention to denote the bases.)
In practical, large-scale usage, the default merging algorithm works better than the default rebase algorithm. But I did switch teams from using a rebase workflow to a merge workflow and manual conflict resolution needs went way, way down. Obviously there are confounding issues, but that's my experience.
If your patches never touch the same files as others, I think it doesn't matter. But, IIRC, if patch A and patch B both touch file F, and the changes in patch A are in context for diffs of patch B, it always fails if patch A changes patch B's context, but since merging incorporates all changes at once, these separate context changes don't apply.
It's been a while, but it might be only when you need to manually resolve patch A, then you also have to manually resolve patch B even if you wouldn't have had to touch it in a merge scenario.
> In practical, large-scale usage, the default merging algorithm works better than the default rebase algorithm.
You're referring to having to do conflict resolution for each commit in the rebase series, as opposed to all at once for a merge. Either way if the upstream has added thousands of commits since the last time, you're in for no fun.
This is a case where Git could be better, but as I responded to u/gioele there exist tools that greatly help with the conflict resolution issue, such as this one that I wrote myself:
which basically bisects to find the upstream commit that introduces a conflict with each commit in the rebase series.
This has one major advantage over merge workflow conflict resolution: you get the most post possible context for each manual conflict resolution you have to do! And you still get to have clean, linear history when you're done.
As usual, explain how you're going to power heat pumps in the Northern half of the country during a 3 week bomb cyclone. There are answers and they cost money.
The only answer we're using is to build 1:1 natural gas capability for solar, which is roughly double the cost. That's a solution, but it needs to be accounted for when comparing options.
Alternative to natural gas? Wind, geothermal, or nuclear. Wind is already in the northern half of the country and operates well when winterized, unlike the ones in Texas that broke since they were not winterized during that freeze a while back.
Natural gas and fossil fuels are not our only options, they are the easiest options.
It's also like to see a comparison to giving people/companies a discount if they have alternative methods of heating for 3 weeks and agree to be powered off. Places like hospitals and universities often have generators and do this. Sand "batteries" (aka electric resistive heaters in a few tons of sand heated to 1000°C) might be cost-effective if standardized. You keep it insulated and hot until the power goes out, then you let it bleed heat out to keep you from dying.
They get cheaper electric rates by agreeing to be the first loads shed if the grid is overloaded. This is a standard thing. If their generators didn't start, they wouldn't be cut off, but it'd be a big deal.
> You’re ok if governments give up and simply tell consumers “you deal with it”?
Paying people to be prepared and willing to go without electricity in times of extreme supply-demand balance is a part of the solution. It's a regular thing for data centers, hospitals, etc. It may be cheaper to pay people to install sand batteries than to install longer-distance interconnects, and if people voluntarily agree, why would you object?
Context is solar and pricing. You can't only build solar, because people will freeze to death. So you can't say "solar+batteries is only $X/W!!!” because you're ignoring that you must also have a rarely-used natural gas, or install a rarely-used long-distance transmission line, or install rarely-used storage capacity. Which is fine, but you're being dishonest about costs if you don't.
Yes, but you have to pay for a line you don't plan to use much, so its capital costs should be attributed to the generation method requiring it. Which is fine, but not including it is dishonest about the true costs.
I think if you designed and built it with the idea in mind that you're building your renewables in the sunny/windy centre/south of the US to be transported to a these places all year round it's a better idea than it being a backup. But I agree that the cost of over generation should be factored in to comparison pricing. But I also think we don't include enough of the costs in FF infra either.
The coal plant in my hometown was always running on cold days. It didn't need anything else to be available when needed besides several hours of lead time.
Mostly relying on long-distance transmission has high costs in capex, opex (losses), reliability, and security.
I'm not sure how often the upper Midwest gets Dunkelflaute. If rare enough, then overbuilding wind is a possible solution (especially combined with additional transmission) but, again, those costs must be accounted for or the solar costs are dishonest.
GP only has two panels that generate 960 W (I’m going to generously assume NMOT and not STC). That’s hardly anything, and certainly not what I would use to try and charge 10 kWh of battery like they’re suggesting.
But sure, I agree it would help if battery prices came down.
During the day when nobody's home the panels are charging the battery.
Obviously more panels are better.
The goal is to be able to run a small window AC unit and various small appliances at night. That's a tremendous quality-of-life upgrade for a huge number of people. $1000 USD would make it somewhat affordable, in the window for a viable small business/NGO opportunity. There's obviously a whole lot more (installation, labor, maintenance, etc), but material cost needs to be low for it to work.
It has many language bindings, including python and js. Though the js backend is not parallel because it uses wasm, and we had problem with mimalloc memory usage with pthread enabled.
Consider making a standoff: a hollow cylinder. You take a cylinder primitive and subtract a cylinder primitive with a smaller radius. If they have the same height, the top and bottom faces of the cylinders are exactly the same plane, which the Preview gives odd effects. The old recommendation is to name your subtracting cylinder taller and shift it down a little, so those faces don't share a plane. Manifold doesn't care.
It does it every time I save the file instead, basically the regular openscad workflow of update-on-save, but instead of doing a preview it’s just full rendering all the time.
reply