> So I start by creating a few empty-ish commits that are roughly analogous to the tasks you'd break a ticket down into.
This is absolutely wild to me, and admittedly not a way I've ever imagined source control being used. I can't say that I have a fully developed opinion of it, but I have a feeling this would drive me nuts as a reviewer. It seems like you're using source control to craft a descriptive history around your changes, designed to tell a story you wanted to tell rather than the messy, authentic history that reveals the struggles you went through and problems you solved along the way. But by doing so, you're creating a fabricated history and losing the aspect that is more like an audit log. So I would just not trust any of it other than the outcome.
I simply don't give much value to human narratives about code, so that's why I prefer a messy history that's a reliable log of the steps you actually went through over a narrative history that might be nicer to read.
If I've already pushed my branch, typically I have a draft PR open and tests are being run against it, and I'm not going to force push, because that's obnoxious and I've probably prohibited it in the repo.
If it's a local commit and I catch it in ten seconds, I will sometimes throw up in my mouth a little bit as I amend the commit.
I view source control as one of the best places for an immutable log of events, and prefer immutable logs for many things in general, for a variety of reasons. So yes, I fix forward.
> the function was actually last changed in 2016, but someone modified it last month only to revert the change before submitting a PR
I can't think of a specific example from my own history, but something like this is what has happened. A function was changed in order to support a different change elsewhere in the code. That other change was later modified, incompletely, to remove the need to modify the first function, and the change to the first function was subsequently reverted. Down the road, it's discovered that the modification was incomplete, and when reviewing the new code, you wonder, "how could this possibly have ever worked?" The answer is that it didn't, and when it was committed, there was another supporting change that made it work. By erasing the history of that other change, you remove the possibility of discovering the reasoning behind the change and the source of the introduction of a problem.
If I had seen that intermediate state that's been erased, remember it, and try to find it, now I'm being gaslit by source control, because I remember a real change that was there in a commit, but source control now will lie to me and tell me that it never existed.
> You said "actual" as-if it was somehow inherently better because it's the "actual" history. But it isn't the "actual" history. So your communication on this point just becomes befuddled. Please be more precise.
actual: "Existing in reality and not potential, possible, simulated, or false: synonym: real."
history: "A chronological record of events, as of the life or development of a people or institution, often including an explanation of or commentary on those events."
One of these things is a representation of the state of a codebase at a point in time. The other is a representation of a state of the codebase that never existed at any point in time.
> our positions are different by degrees than by categories
Absolutely not. I'm not sure how to interpret your comments as other than that you may not understand what rebase is actually doing.
A commit is a snapshot of a codebase at a point in time. If you commit when you've run your program, recording a point along the path of modifying the code where you've observed the codebase to be consistent, rebasing retroactively changes the snapshot of the codebase to something that you have never examined.
If foo.c defines a function foo that calls a function bar in bar.c, and you've updated the way that you call foo in foo.c and someone else updated the behavior of bar in bar.c, the act of rebasing in itself can change the output of your program without recording the step of making that change, and without you ever observing the program's behavior after that change (and before any other commits you've presumably made to get your code to its current state).
Are we at least on the same page that rebasing in itself makes changes to the atomic bits of recorded history, irrespective of what the size of those atoms are? You seem to be fixated on the size of steps being recorded, which is completely irrelevant to the point that rebase is retroactively changing the composition/snapshot of each step. The difference is between an immutable log of immutable events and a mutable log of mutable events. One of those is easier to reason about.
> You have too! Unless you're recording every keystroke, which I assume you are not.
Surely you can understand the difference between omitting less interesting points along a timeline and literally changing what was recorded retroactively for points that have been selected as meaningful along that timeline?
> More curation makes this easier, not harder.
Not when "curation" is revision after the fact. What you're describing as "curation" is changing the recorded/published history from states that were intentionally recorded and examined to new states that never were even run or examined anywhere. When I'm trying to answer the question "how did this ever work?" or "what were they thinking" and the answer is "it didn't", because they committed something different, this makes troubleshooting and determining intent infinitely more difficult and complicated.
> A risk for sure. Not a big one in practice in my experience.
I've definitely spent days of my life trying to track down inexplicable problems in other people's code as a result of their rebasing, that cannot be fully explained because the history of what they actually committed was erased.
> And you can always configure CI to run on each commit, although the tooling to do this isn't great these days.
What are you even calling "continuous integration" if you're not running tests on every commit? This also highlights that if you were doing that, which I do, and you should be, that history becomes misleading after a rebase unless you re-run tests against every commit.
> you think the choice is between "actual" history and curated history, when in reality, the choice is between some incidental curation and intentional curation
Again, do you not understand the difference between capturing something that actually occurred and changing that capture to be something that never occurred? Your curation is literally a series of lies about the code (that I understand you may find easier to read and more convenient for the goal of forming a high level understanding of the changes over time), whereas what I prefer is a faithful recording of history. The integrity of this captured history matters a lot when you're dealing with executable, deterministic code, and the outcome of running a program can be changed by your "curation".
So now you've erased the record of your actual process, that might be revealing later to someone who's trying to figure out what the heck you were thinking, for the sake of trying to create a history that looks more linear or tidy than the reality of what happened, and, if you're not running tests and re-evaluating all the intermediate steps along your history, introducing the possibility that you've invalidated something that worked at one of those points in history and no longer does after you rewrite it.
This strikes me as a crazy fastidiousness over making your history look the way that you want it to look, rather than preserving the actual history, which is detrimental to the value of being able to find out what actually happened when something goes wrong.
I wonder if the difference here is in what your quality threshold for a commit is. I commit when I reach a point of coherence in the code, and ensure that the code passes tests before I commit. Each commit is thus a checkpoint of coherence, where the points in between may be out of order or failing tests.
Maybe I just don't consider "saving your work" to be a valid use case for commits. Use an IDE or other local tools for that. Commits are points that are worth saving (or "publishing" if you prefer) beyond your local workspace.
This isn't a novella. We're talking about executable code. What you're suggesting is the equivalent of using an encyclopedia as a legal reference.
Merge commits tell the coherent story. Commits reveal the messy history that got you there, which is critical exactly when you need to look at history. If you're not trying to track down the source of a problem and how it was introduced, in a deterministic way, why do you bother keeping source history? Publish pretty changelogs instead.
Okay, but rebasing is changing each point in time of that history–that you curated by choosing when to commit–to be something different from what it ever was, retroactively. It's literally creating an entirely new history that nobody has ever actually examined, introducing the possibility that points along that history are inconsistent with what was intended at the point of each commit.
> rebasing creates a cleaner, more understandable history & state of the world without the clutter of merge commits
"Cleaner", for some definition of "clean". In this case, pretty, not accurate.
I just can't understand the draw of rebase based workflows. It seems to be an expression of a preference for aesthetics over accuracy. What is the point of source control, other than to reliably capture what actually happened in history? As soon as you start rewriting that, you compromise the main purpose.
Using merge commits preserves what you actually committed. If you ran tests before you committed, rewriting that commit invalidates that testing. If you need to go back and discover where a problem was introduced or what actually happened, with certainty, in a commit history, rebase undermines that, because it retroactively changes your commits.
It's like a huge portion of the industry is collectively engaging in a lie, so that our commit histories look prettier.
The US is way down the list at 120 for income equality, worse than most of the "developed world". That median hides a lot in a country of over 320 million.
> Weapons are uniquely special in that they are specifically designed to maim and kill. Via defense or justified actions is irrelevant; it's a tool of war. Arguably, if there was E2E software that was specifically designed to maim and kill it might be received in a similar manner as guns.
This is nothing more than a politically motivated lie.
You cannot escape the fact that guns are overwhelmingly used for peaceful purposes that do not include maiming and killing. If this were not the case, Americans would all be dead or maimed by the guns that outnumber people in our country.
Even where the evidence strictly supports your claim, it counters the intent you imply. FBI standards for selecting ammunition, for example, test penetration through clothing and material designed to simulate a human body, but the intent is to stop lethal threats with a minimum of collateral damage. Quite opposite to being "designed for slaughtering", they are designed to minimize harm, while serving a defensive purpose.
> Via defense or justified actions is irrelevant
I think you'd find the opposite to be the case if a person were threatening your own life.
This kind of blows my mind about this, and I'm surprised that everyone seems to be focused on conspiracy theories about Cloudflare instead of the apparent situation that archive.is is intentionally breaking fundamental behavior of the internet because they don't they aren't getting information they want from Cloudflare.
Internet protocols were designed to be redundant and resilient, so that things still work when things break and traffic takes other paths. When people do shit like this, we get a less reliable, less functional internet. Demanding to know the exact subnet a request originated from, and returning incorrect results when that information is not given, seems to me a thoroughly hostile behavior on the part of archive.is.
And you have also missed the point. You are correct that they don't have to be dangerous in that situation, but what you describe relies on everyone around you driving in a perfectly calm, rational, coordinated manner, which is not what happens in reality. Driving with the expectation that everyone around you is a protocol droid is unrealistic and dangerous.
What I described is what actually happens in that scenario, and unfortunately I only have control over my own actions, not those of "everyone behind them".
If you're deliberately ignoring reality and blocking a line of traffic, telling yourself, "these people don't have to be dangerous", the only things you're accomplishing are self-delusion and making the road more dangerous.
Stay to the right except to pass. It's really not that difficult.
I'm not talking about situations with two vehicles on the road. What happens with regular traffic is that you get someone driving 75mph in the right lane and another driving 75mph in the left lane, and it's game over for the whole highway. Once a few more vehicles accumulate, there's no safe driving stance. If you stay in the left, a gap develops on the right and people coming up to the jam pass to the right and then unsafely merge in. If you stay on the right, people passing others on the right are closing on you at ridiculous speed, or you're stuck driving a couple of feet away from another vehicle (on your left) that's tailgating and being tailgated and jockeying for position.
Taking the stance of "I'm traveling the speed limit, so I can stay in the left lane as long as I want" ignores the reality that there are other drivers that don't necessarily agree with you. Staying right except to pass minimizes the risk to everyone involved, accommodating both conservative drivers and aggressive or unsafe drivers, and lets everybody coexist. Staying left increases the danger and promotes road rage and other unsafe driving behaviors such as tailgating and right-lane passing.
No, you continue traveling at a safe passing speed until there's space to safely move to the right at let the faster vehicle pass. Just be courteous, basically, and don't play vigilante to "enforce" one rule (speed) while ignoring another (keep right except to pass, and the probably unwritten, pass quickly).
I certainly never said that speed limit plays no part in the equation, but I believe that safe speed for a given combination of vehicle and road and traffic conditions is much more significant than the legislative limit.
Your question works just as well when the example is reversed: if someone is blatantly disregarding lane discipline, why should I expect them to drive safely in any other regard (and why wouldn't I try to put as much distance between me and them as possible)?
200mph vehicle in this case is an asshole if:
a) she doesn't slow down and leave a safe distance between you and her in order to let you finish passing
b) she otherwise creates a dangerous situation from excessive relative speed, which would probably be the case most of the time if she's going that speed around other traffic
No. Stop it. This attitude is consistently responsible for the most dangerous road conditions I see driving in America.
Keep right except to pass. Period.
Everybody traveling the same "maximum speed limit" is a fantasy and rarely exists in reality. There are lots of good reasons for traveling over the speed limit (quickly passing to avoid prolonged travel in close proximity to another car, for example).
Left lane cruisers inevitably lead to long queues in the left lane with empty lanes to the right, which leads to people passing on the right, tailgating, and a host of unpredictable situations that increase the danger on the road much, much more than simple speed (duh, many speed limits are arbitrary and political, not based on some absolute "maximum safe speed", which is a ridiculous notion anyway for roads that carry both sports cars and heavy tractor trailers).
Your prescription creates situations in which it is literally impossible to drive safely (and frankly, I'm sick of finding myself in these dangerous and completely unnecessary situations because of Americans' insane (and sometimes illegal[1]) driving practices...I don't want to race anybody, I just want to get to my destination safely and efficiently). Even choosing to waste your time being the slowest car on the road in the right lane, you end up being put in danger by cars trying to right-lane-pass with dangerous closing speeds up to dangerously close distances.
I didn't say I wanted to offer you service, just your neighbor. He's more profitable. You don't get to benefit personally from all the interruption, but in order to have anything approaching a free/competitive market, you'd have to tolerate it.
This is absolutely wild to me, and admittedly not a way I've ever imagined source control being used. I can't say that I have a fully developed opinion of it, but I have a feeling this would drive me nuts as a reviewer. It seems like you're using source control to craft a descriptive history around your changes, designed to tell a story you wanted to tell rather than the messy, authentic history that reveals the struggles you went through and problems you solved along the way. But by doing so, you're creating a fabricated history and losing the aspect that is more like an audit log. So I would just not trust any of it other than the outcome.
I simply don't give much value to human narratives about code, so that's why I prefer a messy history that's a reliable log of the steps you actually went through over a narrative history that might be nicer to read.