If only there were some way to logically break up large pull requests into smaller pieces... Some way of creating a checkpoint with a diff including your changes, and some kind of message explaining the context behind the change... some way to "commit" a change to the record of the repository...
Part of the idea behind stacked PRs is to keep your commits focused and with isolated changes that are meaningful.
A stacked PR allows you to construct a sequence of PRs in a way that allows you to iterate on and merge the isolated commits, but blocks merging items higher in the stack until the foundational changes are merged.
Stacked PRs tend to encourage a series of well-organized commits, because you review each commit separately, rather than together.
What they do that the single branch cannot is things like "have a disjoint set of reviewers where some people only review some commits", and that property is exactly why it encourages more well-organized commits, because you are reviewing them individually, rather than as a massive whole.
They also encourage amending existing commits rather than throwing fixup commits onto the end of a branch, which makes the original commit better rather than splitting it into multiple that aren't semantically useful on their own.
I think the point the GP was trying to make is that the GitHub UI ought to be able to allow you to submit a branch with multiple well-organized commits and review each commit separately with its own PR. The curation of the commits that you'd do for stacked PRs could just as easily be done with commits on a single branch; some of us don't just toss random WIP and fixup commits on a branch and leave it to GitHub to squash at the end. I.e., it's the GitHub UI rather than Git that has been lacking.
(FWIW, I'm dealing with this sort of thing at work right now - working on a complex branch, rewriting history to keep it as a sequence of clean testable and reviewable commits, with a plan to split them out to individual PRs when I finish.)
> I think the point the GP was trying to make is that the GitHub UI ought to be able to allow you to submit a branch with multiple well-organized commits and review each commit separately with its own PR.
That's what this feature is, conceptually. In practice, it does seem slightly more cumbersome due to the fact that they're building it on top of the existing, branch-based PR system, but if you want to keep it to one commit, you can (and that's how I've been working with PRs for a while now regardless, honestly).
They confirmed in other comments here that you don't have to use the CLI, just like you don't have to use gh in general to make pull requests, it's just that they think the experience is nicer with it. This is largely a forge-side UI change.
> I think the point the GP was trying to make is that the GitHub UI ought to be able to allow you to submit a branch with multiple well-organized commits and review each commit separately with its own PR
So the point he's trying to make is that Gituhub UI should support Stacked PRs but call them something else because he doesn't like the name?
Not really. Without seeing the entire changeset for a PR, you'd have to mentally keep track of what the current state of everything is unless you're a commit minimalist and presquash.
If we're speaking strictly code review, because you can actually make sense of the changeset for the child PR by not including its unmerged parent's changeset.
I've done this manually by building a big feature branch and asking an LLM to extract out functionality for a portion of it.
For the former, it would seem to split based on frontend/backend, etc. rather than what semantically makes the most sense and for the latter it would include changes I don't want and forget some I do want. But I haven't tried this a lot.
Probably 90% of my coworkers in a US tech company are on a work visa. Now that there is pressure on the H1B program, my company is investing in a permanent engineering team in India. Whether this will pay off for them in the long term is a matter of debate, but it seems like the near-term future of the US engineering team is in serious doubt.
You can't just "dismantle H1B" and expect it not to backfire.
As 75% of a single month fee (25% paid upfront), not too bad either: $46k in total for 4 weeks of work. Expenses were not included (flight was paid for).
Yep this was probably the most LLM generated thing I've read all day and that's saying something. Brutal.
Everyday I see dozens of huge posts where someone has generated a wall of text that's expressing a very simple, very derivative idea and I see tons of earnest people replying with posts that the they've written themselves seemingly unaware of this and it really pisses me off to be honest. If you are going to generate your thinkpiece like this there should be an international law that says it can't be longer than two sentences.
In fact, the whole article is filled with slopisms, just with the em dashes swapped for regular dashes and some improper spacing around ellipses to make you think a human wrote it.
Shift-left was a disaster? A large number of my day to day problems at work could be described as failing to shift-left even in the face of overwhelmingly obvious benefits
I clicked the article thinking it was about GitLab. Much of the criticism held true for GitLab anyway, particularly the insanely slow feedback loops these CI/CD systems create.
You can though. GHA and Gitlab CI and all the others have a large feature set for orchestration (build matrices, triggers,etc.) that are hard to test on a local setup. Sometimes they interfere with the build because of flags, or the build fails because it got orchestrated on a different machine, or a package is missing, or the cache key was misconfigured, etc.
There are a bunch of failures of a build that have nothing to do with how your build itself works. Asking teams to rebuild all that orchestration logic into their builds is madness. We shouldn’t ask teams to have to replicate tests for features that are in the CI they use.
Indeed there are. But you iterate on local and care about CI once everything is working in local. It's not every tuesday I get CI errors because a package was missing. It's rare unless you're in those 1000-little-microservice shops.
It is rare for our run of the mill Java apps to however, we notice it with:
Integration of code quality gates, documentation checks, linting, cross architecture builds, etc.
Most of this can be solved by doing the builds in a docker image that we also maintain ourselves. Then what remains is the interaction between the ci config for matrices, the tasks/actions to report back quality metrics, the integration with keyvaults to obtain deploy time secrets, etc.
Then there are the soft failures, missing a cache key causing many packages to be downloaded over and over again, or the same for the docker base images, etc.
We fix this for our 1000+ microservices, across hundreds of teams by maintaining a template that all services are mandated to use. It removes whole classes of errors and introduces whatever shenanigans we introduce. But it works for us.
If GHA, Azure Pipelines, etc., would provide a way of running builds locally that would speed up our development greatly.
Until then we have created linting based on CUE to parse the various yamls, resolving references to keystores, key ids, templates, etc., and making sure they exist. I think this is generic enough to open source even.
> Authorities, citing a “foregone conclusion exception” to the Fifth Amendment, argued that Rawls could not invoke his right to self-incrimination because police already had evidence of a crime. The 3rd Circuit panel agreed, upholding a lower court decision.
I do not follow the logic here, what does that even mean? It seems very dubious. And what happens if one legitimately forgets? They just get to keep you there forever?
This is an area that seems to confuse a lot of people because of what the 5th amendment says and doesn't say.
The reason they can't force you to unlock your phone is not because your phone contains evidence of stuff. They have a warrant to get that evidence. You do not have a right to prevent them from getting it just because it's yours. Most evidence is self-incriminating in this way - if you have a murder weapon in your pocket with blood on it, and the police lawfully stop you and take it, you really are incriminating yourself in one sense by giving it to them, but not in the 5th amendment sense.
The right against self-incrimination is mostly about being forced to give testimonial evidence against yourself. That is, it's mostly about you being forced to testify against yourself under oath, or otherwise give evidence that is testimonial in nature against yourself. In the case of passwords, courts often view it now as you being forced to disclose the contents of your mind (IE live testify against yourself) and equally important, even if not live testimony against yourself, it testimonially proves that you have access to the phone (more on this in a second). Biometrics are a weird state, with some courts finding it like passwords/pins, and some finding it just a physical fact with no testimonial component at all other than proving your ability to access.
The foregone conclusion part comes into play because, excluding being forced to disclose the contents of your mind for a second, the testimonial evidence you are being forced to give when you unlock a phone is that you have access to the phone. If they can already prove it's your phone or that you have access to it, then unlocking it does not matter from a testimonial standpoint, and courts will often require you to do so in the jurisdictions that don't consider any other part of unlocking to be testimonial.
(Similarly, if they can't prove you have access to the phone, and whether you have access to the phone or not matters to the case in a material way, they generally will not be able to force you to unlock it or try to unlock it because it woudl be a 5th amendment violation).
> excluding being forced to disclose the contents of your mind for a second
This seems like a key point though. What's the legal distinction between compelling someone to unlock a phone using information in their mind, and compelling them to speak what's in their mind?
If I had incriminating info on my phone at one point, and I memorized it and then deleted it from the phone, now that information is legally protected from being accessed. So it just matters whether the information itself is in your mind, vs. the ability to access it?
There are practical differences - phones store a lot more information that you will keep in your mind at once.
You can actually eliminate phones entirely from your second example.
If you had incriminating info on paper at one point, and memorized it and deleted it, it would now be legally protected from being accessed.
One reason society is okay with this is because most people can't memorize vast troves of information.
Otherwise, the view here would probably change.
These rules exist to serve various goals as best they can. If they no longer serve those goals well, because of technology or whatever else, the rules will change. Being completely logical and self-consistent is not one of these goals, nor would it make sense as a primary goal for rules meant to try to balance societal vs personal rights.
This is, for various reasons, often frustrating to the average HN'er :)
> This is, for various reasons, often frustrating to the average HN'er :)
With that in mind...
> Being completely logical and self-consistent is not one of these goals, nor would it make sense as a primary goal for rules meant to try to balance societal vs personal rights.
Do we really know that it wouldn't make sense, or is that just an assumption because the existing system doesn't do it? (Alternatively, perhaps a consistent logical theory simply hasn't been identified and articulated.)
This reminds me of how "sovereign citizens" argue their position. Their logic isn't consistent, it’s built around rhetorical escape hatches. They'll claim that their vehicle is registered with the federal DOT, which is a commercial registration, but then they'll also claim to be a non-commercial "traveler". They're optimizing for coverage of objections, not global consistency.
What you seem to be telling me is that the prevailing legal system is the same, just perhaps with more of the obvious rough edges smoothed out over the centuries.
It means that if all the other evidence shows that the desired evidence is on the computer, then it is not a question of whether it exists, so youre not really searching for something. Youre retrieving it. That doesn't implicate the 4th amendment.
Unlocking/forced unlocking is not a 4th amendment issue, but a 5th amendment one.
The 4th amendment would protect you from them seizing your phone in the first place for no good reason, but would not protect you from them seizing your phone if they believe it has evidence of a crime.
Regardless, it is not the thing that protects you (or doesn't, depending) from having to give or otherwise type in your passcode/pin/fingerprint/etc.
Fair check! I use it to polish my phrasing (especially trying to keep up with this thread volume), but the 'scars' and the management experience behind the comment are 100% human. Point taken though—I'll try to keep it rawer
reply