The problem is that when someone breaks into your house, you have no idea what they are capable of. Are you willing to give someone performing a home invasion the benefit of the doubt? I'm not advocating for blindly firing away at anyone in your house, but I'm also not judging someone who has firearms in the house to protect their family.
This is an oversimplification. If someone is in your house and especially if you have kids you are going to do whatever you can to protect your kids not have a conversation with the burglar or warm him off with aiming a weapon. You don’t know if he’s armed and what he’s capable of, just that he’s in your house and potentially everyone’s life is in danger. I agree with you when someone steals a car from the front yard and the homeowner has legal basis to shoot that person over their car but in my home? It’s life or death.
Because time in the real world uses leap seconds. The time businesses open and close. The times reported in news articles. And so on. What facebook wants is for all of them to stop using leap seconds so facebook’s infrastructure is simpler
The article you linked seems to be arguing pretty strongly against leap hours. I'm not sure we could solve all those problems even in 3000 years. Can we compromise and use leap minutes? That way the problem is a bit more immediate, in 50 years we're sure to have solved it; or we'll all be dead and it will be on someone else!
Instead of leap hours we could just permanently abandon leap anything, and state that the offset between UTC and TAI is fixed at 27 seconds from now on, forever. Every few thousand years, when this new UTC has drifted enough from solar time on the prime meridian for people to start noticing and caring, countries can decide to simply change their offset from UTC, which will just be a normal update in the time zone database that doesn’t need to be coordinated with anyone else, i.e. something that already happens quite regularly.
This is all quite hypothetical as it’s hard to predict whether anything like our current technological civilization will exist thousands of years from now, but even if it does, a simple mechanism exists to avoid problems (just have each jurisdiction change their local time when they decide they want to).
I can’t see any downsides for literally anyone from this proposal, other than the insignificant downside to the British that they will lose the prestige of being the place that global standard time is based on.
It infuriates me that the BBC World Service insists on announcing the time as "<something> GMT", pronounced in a smug tone of voice. The GMT timescale no longer exists; nobody broadcasts it. What the announcers are broadcasting is the BBC's ignorance. I find it embarrassing and jingoistic.
They've also adopted an idiosyncratic way of pronouncing the time itself: "The time is Four, GMT". Everyone else says "Four O'clock", or "four hundred hours" or "four AM". The Beeb are almost completely immune to complaints; they've outsourced their complaints department, and the contractor's brief is to make sure no complaints reach programme makers.
This is not about deaths (mass extinctions usually not follow from resource exhaustion, but from some crisis), this is about less people being born. Which is how human population self-regulates given the estimation of resource availability.
That’s assuming they ever even make it to net positive energy output. The article carefully avoids mentioning that the lasers they use are wildly inefficient. It is very hard to break even when you lose 90% of your input power right at the start
But the relevant question is, how efficient are equivalent modern lasers? NIF was built in the early 2000s and laser technology has advanced quite a bit in the past couple decades.
The lasers they use are extremely specialized, since they have to deliver outrageous amounts of power for a very short period of time. Advancements in normal lasers may not be of much use here
Edit: Wow, looks like they have improved considerably
Yes, and lasers that do exactly that have advanced very quickly. We're up to multi-petawatt picosecond lasers now. We're getting high repetition rates instead of the once or twice per day of NIF, by using laser diodes in place of flashlamps. There are dozens of extreme laser facilities operating or under construction all over the world. And if I'm not misinterpreting this, efficiency is as high as 60%:
In most of the US they aren’t common. Outside of that debacle in Texas, I can’t recall any rolling blackouts in the US from lack of supply. The rarity is quite likely why that event made international news and got so many people around the country talking about it
This comment would be more compelling if it gave any hint about what aspect of the tooling the author didn’t understand or what they should be doing differently.
I’m not talking about the author, specifically or criticizing them directly. I’m lamenting how often I encounter people putting intense amounts of effort into arguing about how git should be used. My hypothesis is that if people understood their tools better before getting all evangelical about forcing their entire eng team to work in their style, others wouldn't have to spend so much time trying to convince them that other styles are exist and are valid.
Compare with a construction site: there are obvious uses for tools and there are less obvious uses and I haven't been on a single one where tools are only used specifically in one way for the entirety of the project. They’re used dynamically by different people with different experiences in order to complete the project. Nobody forces other workers to use a specific grip when holding their hammer…
This isn't "how to use a hammer", though, it's more like "how to evaluate the completion of work", which is definitely something working teams have to agree on. git itself is almost irrelevant to the discussion, other than its native feature set having some influence on the options.
If this was just about team review workflow I wouldn't expect to find "easier to rollback" and "don’t need to wait on a particular change to be merged" to be on the list of upsides, as these are properties of the repository structure and not the review workflow.
> "easier to rollback" and "don’t need to wait on a particular change to be merged" to be on the list of upsides
Can you explain how these are not just facts? We’re not using stacked branches because it has enough downsides, but these are indubitably upsides of stacked branches.
Stacked branches tend to produce repository structures that make this easy, but so do lots of other development practices. It is not related to "how to evaluate the completion of work", it's entirely about how you use the hammer.
I can't be certain what dcow is referring to but there are a few things that point to confusion, or maybe an overambitious attempt at simplification.
For example, Stacking PRs keeps the author unblocked. Authors don’t need to wait on a particular change to be merged before starting to build something on top of those changes.
This will fundamentally be up to the author's git skill whether or not they are presenting the PRs to reviewers / mergers as stacked. If they're skilled git users there's little to no cost presenting them one at a time and keeping the not-yet-PRd branches fresh. If they're not skilled git users, they have no hope of managing multiple PRs effectively only be virtue of presenting them all at once.
Or: Since stacking PRs allows you to create a DAG of dependent changes, this natually allows you to manage code changes that need to be submitted in a particular order.
Assuming this is in a single repository, a fast-forward-only commit policy alone ensures this.
Or: stacked PRs use branches, and can have multiple commits in a single atomic change; stacked commits use a single commit as the unit of atomic change.
Stacked PRs usually use branches, but stacked commits also still use at least one branch and could have more. In both the commit is the unit of atomic change, because that's what a commit is.
I'll also add I find the entire language around "branchless" workflows in git confusing, not just from this author. There is no such thing; considering one special branch as "not a branch" or your local and remote and someone else's remote as the "same branch" just because they have the same name is a holdover from older/other VC tools. We don't do any new git users a pedagogical or practical favor by clinging to that view.
> This will fundamentally be up to the author's git skill whether or not they are presenting the PRs to reviewers / mergers as stacked. If they're skilled git users there's little to no cost presenting them one at a time and keeping the not-yet-PRd branches fresh.
On multiple teams I've worked on, this has been explicitly discouraged because reviewers often want to see the changeset in as much context as is available, including future changesets.
What's better context than presenting all the related atomic commits at one time in a single pull request so you know exactly which related set of commits are being added and for what reason? Slap a merge commit on and you can revert the whole thing! But your commits are a mess, and I want to see clean ones. That is what interactive rebase is for and what attentive project contributors would do in order to clean up before or during the merge process. Why is it fair to ask someone to change syntax formatting to but not cleanup their commits? Because the latter is a "big ask" for someone who doesn't know their tool.
Then we get back to the problem of not having independent review, CI status, and deployability for each individual changeset. There's no amount of git competency that changes the fact that GitHub PRs operate at the branch level, not the commit level. I've actually done exactly what you say many times -- interactive rebase to clean up the commit history -- but the end result of that process is the creation of multiple "stacked" branches, solely so I can submit multiple PRs and conform with the team's expectations.
> There's no amount of git competency that changes the fact that GitHub PRs operate at the branch level, not the commit level.
Most all CI tools support per-commit checks with simple configuration/scripting of their execution DSL/API. In GitHub, push actions already works this way. You can do the same thing on any branch after a PR is opened: on synchronize you can iterate over all the updated refs, run checks, and publish results to the commit status API https://docs.github.com/en/rest/commits/statuses, and https://docs.github.com/en/pull-requests/collaborating-with-....
git-branchless author here. By "branchless", I mean literally using detached HEAD as the primary state of development. If you're using tools like Gerrit or Phabricator, you never have to explicitly make a branch to get your code merged. If using GitHub, then branches are unavoidable, but it can be nice to do branchless development as part of rapid prototyping (see https://github.com/arxanas/git-branchless/wiki/Workflow:-div...).
Another term you could use is "anonymous branching". This is not technically accurate in the above workflows, but it captures the essence pretty well in Git, more so than "branchless".
But when you call it "anonymous branching" you lay bare that the only advantage is that you don't need to name your work "branch", and meanwhile you have a workflow that's needlessly incompatible with most other git tooling.
In particular, since this is the one I see usually called out as a benefit of branchless:
Stock Git does not have good ways of rebasing a sequence of branches.
A sequence of branches can be rebased by rebasing (or otherwise rewriting) the longest one (the only one you'll need locally) then pushing the individual commits in the current branch to the remote under any relevant branch names. This doesn't take zero time, but with good git UIs it will take less time than remembering `git move`, and it's not especially hard to do with the stock CLI either.
> But when you call it "anonymous branching" you lay bare that the only advantage is that you don't need to name your work branch
Sure, I'm only responding to what you were saying about "There is no such thing; considering one special branch as 'not a branch'". There is such a thing in that there is no branch involved in the detached HEAD state. It's not some kind of Git misunderstanding. I think you might be referring to trunk-based development and always building off of the remote main branch instead of having your own local copy, which is unrelated to being "branchless", for the reasons you stated.
For many people (particularly those on Github!), a branchless workflow won't help, so you're free to not use it. In my opinion, it's a workflow that is better compatible than stock Git with code review tools like Gerrit and Phabricator.
I personally argue that anonymous branching is useful even in some branch-based workflows. Mainly, if Git branches are so lightweight to use, why do we also use the command `git stash`, instead of just always creating a new branch for our temporary work? One benefit of anonymous branching is that it consolidates these workflows in a convenient way. Some people don't stash changes or feel that branching in those cases is heavyweight, so anonymous branching doesn't help them at all.
> then pushing the individual commits in the current branch to the remote under any relevant branch names
If I'm understanding correctly, every time you rebase the longest branch, for each commit in the branch, you would manually run e.g. `git push <commit> origin:my-branch-name`? That seems like it would take a lot of time to me. Is the tacit assumption here that you don't have a lot of commits in your branch, so this doesn't take a lot of time?
> There is such a thing in that there is no branch involved in the detached HEAD state.
But at the very least there's still an existing remote branch, which is the ultimate merge target, for example - perhaps even multiple. Since we're talking about coordination, there's also the actual state at the remote vs. my view of the remote vs. my teammates' views of the remote. But we don't think about this too much, because we can synchronize easily as long as the remote branch has a name. Taking the name off the branch makes it more difficult to do anything with someone else's work other than merge it, e.g. pass a changeset back and forth or hand over a half-complete task.
> why do we also use the command `git stash`, instead of just always creating a new branch for our temporary work?
I have no idea actually, because I don't. I haven't run git stash manually since I learned about autostash, and even before that it wasn't for temporary work but for changes I decided I wanted somewhere else only after writing them. Temporary work mostly does get a branch (usually as a new commit on top of my current local branch).
> If I'm understanding correctly, every time you rebase the longest branch, for each commit in the branch, you would manually run e.g. `git push <commit> origin:my-branch-name`?
Close, except I'd scroll down the list of commits and type `P o RET TAB branch-name` (or something to that effect, it'd be slightly different if I have several remotes). This would take perhaps ~0.5 seconds per branch and not require me to context switch to a terminal.
It does take longer for people using less powerful clients, but virtually all do provide some way to do it even it means a few right-clicks on a menu and clicking some "OK" buttons, and there's value in everyone using analogous operations. And the people using those clients usually can't reliably recover from a large class of "git broke" mistakes, assistance from git-branchless or not, so handing them a CLI and a prayer is out of the question. And even the "long version" is pretty negligible (like, maybe 10 seconds per branch?) compared to everything else you should do to make your changeset approachable for review.
Magit, and the remote branch names are visible in the log view and easy to enter via tab completion. (We're still talking about stacked PRs right? Median stacked at any given time is probably 2 and p90 is maybe 4? Max I've ever seen is ~10 and that was quite a fucked up situation for plenty of other reasons.)
10 seconds would certainly be too long for me. It is obviously not too long for them, or they'd learn some keyboard shortcuts to get the easy 5 out of the way to begin with. But regardless, it's all pretty much dwarfed by things that need actual brainpower like re-reading my commit messages for grammatical errors / broken links / etc.
I see, thanks for the information. I often stack 10+ commits, so I don't think your workflow would be reasonable for me. (For example, here, I have 11 finished commits and 3 in progress: https://github.com/arxanas/git-branchless/pull/451 — but I don't actually use stacked PRs on Github, particularly if no one is reviewing my code. Most of my stacking is at work with Phabricator anyways, which handles this better.)
It’s only necessary to push ten branches, one per commit, if you intend ten separate, let’s say, “review events” though. For that example we would have fewer than that nor would we want that many.
I do stack 10+ commits fairly regularly but that may be only 1-2 reviews.
(I’m not familiar with Phabricator, only Gerrit and GH/GL, as well as some more manual Workflows.)
Right, in this case, I would prefer 10 separate review events. Other than for code review purposes themselves, I would want CI to run on each of these commits individually, rather than only on the result at the end.
You can click on individual commits in a pull request on GH (and in every single git tool I know) to review each commit individually. A pull request is an abstraction over a set of commits. Sometimes it's 1:1, many times it's not. Some large companies force the issue because even though it is more rigamarole for everyone involved, they can afford it. So then people invent silly scripts and coin entire workflows just so they can "push 10 PRs all at once" because they want the efficiency back that a 1:1 commit to PR policy robbed from them. It's all quite silly. FYI many CI systems support running each commit individually, including GH and GitLab.
I (and many developers I know) would use the GitHub individual commit review system, but it has a lot of missing features which make it unreasonable to update commits in the PR. For example, if you rewrite one of the commits in a multi-commit PR, then GitHub loses the association and old comments are lost. Similarly, you can't view the diff between an old and new version of a commit.
As far as I know, Phabricator does not let you view or comment on individual commits in a code review (which I use at work). Let me know if you know differently and I might switch to doing that.
Can you advise me on running CI on each commit in the PR in GitHub? As far as I can see, it's technically possible in that you can run arbitrary code as part of your CI, but there's no convenient way to do it. (In particular, I would want to be able to view the CI runs for each individual commit, i.e. render the little checkmark/x next to each commit in GitHub, which seems like it would require a lot of integration via the API.)
One thing that often happens in a stack is the earlier commits are regularly merged into the main branch while the later commits await review. This helps to keep things in sync in a trunk-based development workflow. Is there a way to split out and merge only the earliest (reviewed and accepted) commits, and leave the later commits pending review, in a tool like GitHub?
Overall, I would like to be able to use GitHub PRs for big stacks, but there seems to be a lot of friction in doing so, to the point where it's more convenient to adopt an alternate code review tool (like Graphite) or PR management tool.
> As far as I know, Phabricator does not let you view or comment on individual commits in a code review (which I use at work). Let me know if you know differently and I might switch to doing that.
Isn't there a "commits" tab when viewing a revision? Also Phabricator is no longer maintained for the last year.
> Can you advise me on running CI on each commit in the PR in GitHub? As far as I can see, it's technically possible in that you can run arbitrary code as part of your CI, but there's no convenient way to do it. (In particular, I would want to be able to view the CI runs for each individual commit, i.e. render the little checkmark/x next to each commit in GitHub, which seems like it would require a lot of integration via the API.)
However, before you do that, consider: this one I think is a slight impedance mismatch between how users conceptually think about using GH and how GH actions are designed to be triggered. The most simple thing to do if you want every commit checked and tested is just make a GH action that runs your checks on push, which gets run on every commit and updates the status. If you already have a push action, just remove the "main" branch restriction. The PR action is designed to do PR-scoped things. You can, if you really only want to check commits once they are opened for PR, iterate over the commit list and manually trigger workflows to test and check each one (you can even just manually trigger your existing push action if you add the manual trigger option and specify the commit sha yourself and it will run, I think). But, is the list of commits that get pushed to the repo and the list of commits you want to eventually test for inclusion into main really that different, at the end of the day?
Please take a moment to remind yourself that different people are in different situations and have different social and technical constraints influencing their decisionmaking, and that people can come to different conclusions from your own for reasons other than incompetence and ignorance. I am sure you are a very smart and effective person, but that doesn't mean that you know what is best for every person in every situation.
That is, in fact, my whole point. There are multiple ways to use your tools--don't assume that people who prefer to use things a different way are ignorant. We completely agree. My challenge is to the frequency at which there is actual need to limit the allowed workflows as a result of different preferences. In other words, let there be a diversity of workflows and deal with it.
More often than not I've seen such limits used to "reign in" "misbehaving" engineers or because, as I've suggested, people sometimes don't know how to use a tool to its full capacity. Sometimes it's purely people wanting to force their preference on others. I've had to walk senior engineers through (or just manually clean up when they clearly have no idea how git works) branches that people royally mess up because they merged something in 8 different ways because some other person told them rewriting history is evil or some previous organization taught them to only push merge commits to PRs or protected all branches or something...
There can both be organizations that need to enforce policy to make their business successful and people that don't really understand the full gamut of what's possible with a tool and restrict workflows to stuff they understand. I don't think I equivocated the two. I simply expressed frustration from all the times I've anecdotally encountered people to aren't fluent with git making decisions for others who are fluent with git on how git should be applied.
That’s not what I’m saying at all. My comment is a meta comment about why we even need to write grand defenses of these practices in the first place. I’ve been “stacking PRs” forever… when it makes sense to do so. There’s no golden git usage pattern. I’ve seen the industry all the rave about gitflow. And then it wasn’t cool anymore with tags being the preference. Now it’s cool to just forgo branch names entirely? I’ve watched teams fight over whether every PR should be exactly one commit because they don’t realize that you don't always have to squash merge if you want two unrelated changes pulled in at the same time—just keep the commits clean and revert doesn't care. My point is that if you know how to use the tool none of this really matters and all seems quite distracting. I no problem with people sharing what works for them, that’s great (as is this article, abstractly).
