Hacker News Reader

Comment by miovoid | Hacker News Reader

Why not to make it part of Git project? Such fragmentation adds complexity and vendor locking.

Presumably because "vendor locking" is pretty much their entire business model

I'm trying to understand what you mean, because it's not obvious to me at all. If you read LKML you'll see stacked PRs has been the norm for years. I'm assuming you want the `gh stack` porcelain into the git cli? We'd first need to add PRs as a porcelain to the git cli for it to make any sense, right?

Gerrit manages stacked changes with standard git tooling, except for the tiny change-id hook. Similar stable change identifier is also what enables Jujutsu to do its magic. Standardizing around something like this would be greatly beneficial, instead a ”gh” CLI is now needed to push a commit.

JJ, Gerrit, codebutler, and I think a couple of others have all basically agreed upon a syntax for change IDs and they are converging their prior ad-hoc formats into one; but last time I checked, the request to the upstream git team of "please don't silently drop the change-id header during rebase or amend" was met with bike-shedding about all the other hypothetical benefits that alternative formats could hypothetically provide, so universal support for the header as used in practice today is still missing D:

(I would love to be proven wrong if there's been some progress that I didn't get the memo about ^^)

This is roughly the current state of things as I know about it, that said I haven't read a lot of git's mailing list lately so it's possible that there have been some other developments.

Reply on news.ycombinator.com