Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Stacked PRs

github.github.com

Post reply on HN
Print view View original

441–450 of 548 posts

Re: GitHub Stacked PRs

#441

Post by skydhash »

rstuart4133 wrote: post #415
skydhash wrote: post #267

Earlier quoted context omitted.

The magic of the git cli is that it gives you control. Meaning whatever you want to do can be done. But it only gives you the raw tools. You'll need to craft your own workflow on top of that. Everyone's workflow is different. > So while I'm working on my branch, I can iteratively make a[...]which means git blame tends to be much more accurate and helpful Everything here I can do easily with Magit with a few keystroke…

> But there's the reflog in git which is the ultimate undo tool. That one sentence outs you as someone who isn't familiar with JJ. Here is something to ponder. Despite claims to the contrary, there are many git commands that can destroy work, like `git reset --hard`. The reflog won't save you. However there is literally no JJ command that can't be undone. So no JJ command will destroy your work irretrievably.

I’ve just tested that exact command and the reflog is storing the changes. It’s different from the log command which displays the commit tree for the specified branch. The reflog stores information about operations that updates branches and other references (rebase, reset, amend, commit,…). So I can revert the reset, or a pull.

Re: GitHub Stacked PRs

#442

Post by smallmancontrov »

alwillis wrote: post #344
smallmancontrov wrote: post #70

Earlier quoted context omitted.

I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git*†‡" and every time I tried it wound up being dog slow (always) or broken (some of the time). Git is fugly but it's fast, reliable, and fugly, and I can work with that.

> I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git". It wasn't the Mercurial team saying it was faster than Git; that was Facebook after contributing a bunch of patches after testing Mercurial on their very large mono-repo in 2014 [1]: For our repository, enabling Watchman integration has made Mercurial’s status command more than 5x faster than Git’s…

No, the "hg is fast" marketing claim that retreated to "hg is Big-O fast and you are dumb for caring about constant terms and factors even if they clearly dominate your use case" predates 2014 and the Facebook patches. These talking points were old in 2010. Mercurial was always dog slow and always gaslighting about it.

I'm glad BigCo made tools to serve their needs, but their needs aren't my needs or most peoples' needs.

> Mercurial has been rewritten in Rust

I'm glad they saw the light eventually! Ditto for the rest of the Rust Tooling Renaissance.

Re: GitHub Stacked PRs

#443

Post by jrochkind1 »

Per_Bothner wrote: post #246
jrochkind1 wrote: post #119

Earlier quoted context omitted.

Welcome to VHS and Betamax. the superior product does not always win the market.

Not always, but in this case the superior product (i.e. VHS) won. At initial release, Beta could only record an hour of content, while VHS could record 2 hours. Huge difference in functionality. The quality difference was there, but pretty modest.

I suppose one lesson could be that there are different dimensions of superiority, different products may be superior in different ways.

Of course, products also can win market dominance for reasons external to the product's quality itself (marketing, monopoly lock-in, other network effects, consumer preferences on something other than product quality itself, etc).

Re: GitHub Stacked PRs

#444

Post by nerdypepper »

whereistejas wrote: post #382
whereistejas wrote: post #380

Earlier quoted context omitted.

Each of your stacked PRs only has one commit. Do you have any examples with multiple commits per PR in a stack? PS: I love the concept of tangled. I currently use `sourcehut` but may soon move to tangled.

nevermind, I see what's happening in the UI. Each `jj` change is preserved in the UI and we can see multiple versions of the same change. The stack then is not really a stack of PRs but a stack of changes (where each change has its own history, i.e., the interdiff view). Did I get it mostly right?

yes, thats right! when you submit a branch, you can choose to "stack" it, so the individual commits in the branch turn into separate PRs. these PRs evolve individually, can be merged individually, and be reviewed individually. you can also set different reviewers/labels for different PRs in the stack.

Re: GitHub Stacked PRs

#445

Post by saagarjha »

zip1234 wrote: post #438
saagarjha wrote: post #427

Earlier quoted context omitted.

A unit of change is a commit. I have no idea why you'd think a PR is a unit of change.

Does your org approve specific commits or PRs overall?

PRs. This is largely why we don't do stacked PRs: they can just be a chain of commits in one PR

Re: GitHub Stacked PRs

#446

Post by Liskni_si »

It's awesome that they're adding a UI for stacked branches¹! The UX of the CLI tool seems weird, though. Why do I need to explicitly create and add branches to the stack if all I really want is to open PRs from my commits? Here's the workflow that I built for myself instead:

∙ `git checkout -b feature-branch-xyz`

∙ make a few commits, perhaps some fixups, rebase, whatever

∙ start tig, look at the history, decide at which points I want to break the branch into stacked PRs, and mark those points using shift-s (which calls my own `git gh-stack branch create $commit` and creates a specially named branch there)

∙ `git gh-stack sync` — collects all the specially named branches, builds a graph of how they're stacked on one another, pushes them, opens stacked PRs

GitHub has had some "support" for stacked PRs for a while, so merging the first one to main will automatically change the target branch of the second to main.

If I need to change anything, I can just `git rebase --interactive --update-refs`, amend commits, split commits, rearrange commits, and then running `git gh-stack sync` will update the PRs for me. If I split a commit in the middle and shift-s to mark it, it will open an extra PR and restack everything to update the order.

Furthermore, the "PR stack" doesn't actually need to be a stack (linear chain), it can be a tree. If I know that some commits are independent of the rest, I don't need to create a separate stack, I just create another local branch, mark PR-ready commits with shift-s, and `git gh-stack sync` will do the right thing. If I need to rebase the whole tree on top of current main, then `git rebase -i --rebase-merges --update-refs` does the job.

I guess what I'm saying is that as someone who's been using git since its inception, it feels much more natural to just do everything in git, and then have a single command that pushes my work to GitHub. And I think this might work even better with jujutsu — just point `git gh-stack sync` at the branches jj makes and it'll make a stack/tree of PRs out of them. :-)

https://github.com/liskin/dotfiles/blob/home/bin/git-gh-stac... if anyone's curious. It's just a few hundred lines of code. Building the graph is done by `git log --simplify-by-decoration`. Opening PRs is shelled out to `gh pr create`.

¹) I mean, I'd much rather they added a UI for reviewing PRs commit-by-commit, with the option to approve/request-changes on each, and the possibility to merge the first few approved ones while continuing work on the rest… But in a world of almost every $dayjob insisting on squash-merging, a UI for stacked PRs is a total game changer, positively.

Re: GitHub Stacked PRs

#447

Post by recursivegirth »

jillesvangurp wrote: post #296
cleverdash wrote: post #30

As a solo dev I rarely need stacked PRs, but the underlying problem, keeping PRs small and reviewable, is real even when you're your own reviewer. I've found that forcing myself to break work into small branches before I start (rather than retroactively splitting a giant branch) is the actual discipline. The tooling just makes it less painful when you don't. Curious whether this changes anything for the AI-assisted w…

It's easier to pile on a lot of changes with AI assisted workflows. And reviewing all that is definitely a challenge just because of the volume of changes. I've actually stopped pretending I can review everything in detail because it makes me a bottleneck in the process. Anything that makes reviewing easier is welcome. To me, stacked PRs seems overly complicated. It seems to boil down to propagating git rebases throu…

I spend more time in planning and steering the AI implementation than I do on reviewing it's outputs.

I do the obvious checks like tests and spin up a dev instance to make sure the feature works like I want it too, but very rarely am I reviewing every line of code these days.

Re: GitHub Stacked PRs

#448

Post by steveklabnik »

puelocesar wrote: post #370
sameenkarim wrote: post #220

Earlier quoted context omitted.

Yes, we handle this both in the CLI and server using git rebase --onto git rebase --onto So for ex in this scenario: PR1: main When PR 1 and 2 are squash merged, main now looks like: S1 (squash of A+B), S2 (squash of C+D) Then we run the following: git rebase --onto S2 D branch3 Which rewrites branch3 to: S1, S2, E, F This operation moves the unique commits from the unmerged branch and replays them on top of the newl…

That’s how I’ve been working for years now. Does anyone know how this gh stacks work internally? Does it do the same thing under the hood? I’m conflicted about it, seems like a good convenience, but I wouldn’t want my team to get dependent on an exclusive feature of a single provider

(You're replying to someone from product at GitHub, they're explaining that's how it works there)

Re: GitHub Stacked PRs

#449

Post by itsdesmond »

withinboredom wrote: post #365
Gabrys1 wrote: post #355

Earlier quoted context omitted.

You can push to GitHub using Sapling. I wish Sapling open source was given more love, as the experience for non-Facebookers is subpar. No bash completion outside the box, no distro packages, no good help pages, random issues interacting with a Git repo...

Sounds like what my teachers used to say: “a personal problem”. Literally nobody outside FB knows what they’re missing and until they fix that, literally nobody cares.

> Sounds like what my teachers used to say: “a personal problem”.

They don’t sound like a very good teacher.

Re: GitHub Stacked PRs

#450

Post by codethief »

aaronbrethorst wrote: post #188
forrestthewoods wrote: post #141

Earlier quoted context omitted.

Worse products win all the time. Inertia is almost impossible to overcome. VHS vs Betamax is a classic. iPod wasn’t the best mp3 player but being a better mp3 player wasn’t enough to claw market share. Google and Meta don’t use Git and GitHub. Sapling and Phabricator much much better (when supported by a massive internal team)

What was the better mp3 player than the iPod?

Anything from iriver.
Post reply on HN