I had more the thought like being skeptical of anyone who would take a job at company Foo or stay there, when they tell you. To me that seems preferable to trying to -- what risks devolving into -- a witch hunt of fall guys (persons), and doxxing people.
I think we are already starting to have that with a couple more infamous other companies in the news the last year: if someone goes to work there, I suspect a lot of people are going to think what is wrong with you, since you must know that company does very harmful things,
Maybe it's time to start wondering that about anyone who'd work for a lot of additional companies?
(I actually had a recruiter recently who was pitching a startup, and the headline featured the "ex-" pedigrees of the founders, including an especially infamous company. I figured any company touting that pedigree as a selling point is probably a bad fit for me. I thanked the recruiter, but said that infamous company as selling point probably isn't a fit. The recruiter seemed to not only understand, but to agree with my vague sentiment about that pedigree company.)
Germany continues to provide arms and support to the IDF and did so throughout the entire duration of the Gaza Campaign. Just recently, the Volkswagen group announced it is considering retooling one of their factories to manufacture missiles for Iron dome system. The UK also continues to manufacture and sell components for weapon systems used by the Israelis. The UK's RAF bases in Greece, Cyprus, and the UK have also been key logistics hubs for weapons to the Israelis and the Americans. In addition, the UK operated daily surveillance flights over Gaza out of their base in Cyprus through the entire period of the Gaza Genocide. The exact goal and nature of this operation continues to be kept secret but it is inconceivable how they weren't witness to the countless war crimes being committed on the ground. Mainstream outlets like the BBC and the Guardian continue to suppress reporting on this story. I am sure there are more countries providing support in secret and in smaller ways. Germany which suspended all arms exports to Saudi Arabia in 2018 citing the murder of the journalist Khassogi and grave human-rights violations in Yemen lifted these restrictions last year citing its defence of Israel. It is illuminating to note how Germany defines the protection of human rights and journalists in these cases.
If I'm following correctly, the conflicts arise from other commits made to main already - you've implicitly caught branch A up to main, and now you need catch branch B up to main, for a clean merge.
I don't see how there is any other way to achieve this cleanly, it's not a git thing, it's a logic thing right?
I've no issue with the logic of needing to update feature branches before merging, that's pretty bread and butter. The specific issue with this workflow is that the "update branch" button for PR B is grayed out because there are these hallucinated conflicts due to the new squash commit.
The update branch button works normally when I don't stack the PRs, so I don't know. It just feels like a half baked feature that GitHub automatically changes the PR target branch in this scenario but doesn't automatically do whatever it takes for a 'git merge origin/main' to work.
> the "update branch" button for PR B is grayed out because there are these hallucinated conflicts due to the new squash commit
Those are not hallucinated. PR B still contains all the old commits of A which means merging would apply them twice. The changes in PR B are computed according to the oldest commits belonging to PR B and main which is the parent of squashed A. That would essentially means applying A twice which is not good.
As for updating PR B, PR B doesn't know where PR A (that are also in PR B) ends because PR A is not in main. Squashed A is a new commit and its diff corresponds to the diff of a range of commits in PR B (the old commits of PR A), not the whole B. There's a lot of metadata you'd need to store to be able to update PR B.
I guess to me, I'm looking at it from the perspective of diffing the repo between the squashed commit on main and the tip of the incoming PR. If there are merge conflicts during the rebase in files that don't appear in that diff, I consider that a hallucination, because those changes must already in the target branch and no matter what happened to those files along the way to get there, it will always be a waste of my time to see them during an interactive rebase.
I don't think we need to store any additional metadata to make the rebase just slightly more smarter and able to skip over the "obvious" commits in this way, but I'm also just a code monkey, so I'm sure there are Reasons.
You’re looking at it from the perspective of a human reasoning. But a computer is a simple machine (what it can do, not how it does it). What seems obvious to you could be a complicated algorithm.
Git store all its information as a directed acyclic graph (a tree) of commits. The leaves of that tree have names, and are what we called branches. Each commit points to a tree (also a tree data structure) where the nodes are blobs (files) and sub trees. But that tree only stores the files that has been changed since the last commit. Git does not store diffs. Diffs are computed as needed.
This why the common ancestor commit is important. From there, a version of the working directory is computed for each branch (main-with-squashed-A and PR B). Files that have not been changed since PR A are ok, but everything else will be different, especially if you’ve modified the same lines.
Squashed A is a brand new commit with a new tree that PR B does not know about. You need to recompute PR B on top of Squashed A, (which will create new commits for PR B).
No, it's a Git thing arising from squash commits. There are workflows to make it work (I've linked the cleanest one I know that works without force pushing), but ultimately they're basically all hacks. https://www.patrickstevens.co.uk/posts/2023-10-18-squash-sta...
Yep that's how I do it if I have to deal with stacked PRs. I also just never use rebase once anything has happened in a PR review that incurs historical state, like reviews or other people checking out the branch (that I know of, anyways). I'll rebase while it's local to keep my branch histories tidy, but I'll merge from upstream once shared things are happening. There are a bunch of tools out there for merging/rebasing entire branch stacks, I use https://github.com/dashed/git-chain.
Sure! Slightly edited the tone, but I’m noticing that often people have idealistic attitudes about FOSS until they get burnt by bad faith actors or even just indifferent corps that have to keep the lights on. Quite unfortunate, definitely not their fault. Pity is correct.
It’s definitely pity. It’s a hard pill to swallow when you were led to believe a certain world view of an entity only to find out they were milking your data.
reply