Conflicts spawn most likely because PR A was squashed, and once you squash Git doesn't know that PR B's ancestors commits are the same thing as the squashed commit on main.
No idea if this feature fixes this.
Edit: Hopefully `gh stack sync` does the rebasing correctly (rebase --onto with the PR A's last commit as base)
> Conflicts spawn most likely because PR A was squashed, and once you squash Git doesn't know that PR B's ancestors commits are the same thing as the squashed commit on main.
Yeah, and I kind of see how git gets confused because the squashed commits essentially disappear. But I don't know why the rebase can't be smart when it sees that file content between the eventual destination commit (the squash) is the same as the tip of the branch (instead of rebasing one commit at a time).
The tip of B is the list of changes of both A and B, while the tip of main is now the squashed version of the changes of A. Unless a branch tracks the end of A in the PR B, It looks like more you want to apply A and B on top of A again.
A quick analogy to math
main is X
A is 3
B is 5
Before you have X + 3 + 5 which was equivalent to X + 8, but then when you squash A on on X, it looks like (X + 3) + (3 + 5) from `main`'s point of view, while from B, it should be X + (3 + 5). So you need to rebase B to remove its 3 so that it can be (X + 3) + 5.
Branches only store the commits at the top. The rest is found using the parent metadata in each commits (a linked list. Squashing A does not remove its commits. It creates a new one, and the tip of `main` as its parent and set the new commit as the tip of `main`. But the list of commits in B still refer to the old tip of `main` as their ancestor and still includes the old commits of A. Which is why you can't merge the PR because it would have applies the commits of A twice.
Even if you tried something like that it will eventually break when other commits are added to main that are not present in PR B, even if those commit don't conflict with neither PR A nor PR B changes.
They didn’t explicitly point to hypocrisy as the thing that makes it “unserious.” Actually I think a lot of serious projects are a little bit hypocritical, a little bit of hypocrisy is often the cost of contact with reality.
In this case it isn’t even clear where the hypocrisy comes from, though. It’s a service for looking up other services. Does it even handle any PII?
It’s not a mystery… I can tell you what I do most days, and probably 80% of it is communication. An AI could do that. That communication is to learn what is going on up, down, and across the org. I mostly want to make sure we aren’t doing redundant work — though sometimes that is useful, and making sure timelines aren’t slipping. Oh, and dealing with conflicts.
The other 20% is writing: policies, SOPs, audits, grants, performance reviews, etc.
I could probably automate over half my job in n8n in a weekend… hmm… actually might try that.
I’m in a heavily-regulated sector, fully remote. If left alone, our junior exec:
- needs a digest of where chat activity is hottest. Maybe he lurks, occasionally he gets into conversations about what’s going on in another department.
- needs some warning if the Microsoft systems are under attack or strain. The Linux systems have not needed attention; the jargon is unfamiliar.
- occasionally brings up hypothetical radical changes in strategy. I think of these as multivariate tests. Maybe I reply, “Plenty of Kubenetes developers available right now” might communicate that some small team would be ahead of us on some solved problem.
I’m surprised that:
- he has no concern that competition even exists. No awareness that our competition demos at conferences; why they’d choose to spend time that way.
- no interest in the big accounts we don’t have. If it would take a big lift, what would engineering need? If it would take a small lift, what non-engineering is blocking? No interest.
- person-to-person networking is effective at all. I just can’t imagine any value in two execs meeting without hours of preparation.
I’ve seen BI tooling around each of these. I wonder if a daily “facts of our department” slide to begin each meeting, if that would replace/augment 51% of visible exec.
I do hope AI will really allow folks to build products with better UX. The problem traditionally is that the UX gets "stuck" - gmail, google maps, they cannot really change because of user's expectations and the big orgs that run them as products. And building new things from scratch was fairly expensive. But now with AI (and modern UI tooling) the equation is at least partially changing.
We have been on this path at work. But I challenge everyone to consider what you lose with MD vs Confluence (et al). It is NOT easier to author, comment on, label, view history of, move without breaking links, etc. markdown docs vs Confluence. If I am the sole author plus my AI and the scope is narrow (a library), I go for MD. But for a big org, process docs, fast iteration… I’m not convinced, until someone builds equally powerful editing UI on top of MD files.
reply