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

491–500 of 548 posts

Re: GitHub Stacked PRs

#491

Post by dontlikeyoueith »

ninkendo wrote: post #294
mh2266 wrote: post #243

Earlier quoted context omitted.

you're upgrading the repository from language version 1 to 2, version 2 adds new compiler errors that rejects some old code, or the library has removed some old deprecated API the repository was still using in some places—the key here being that it can't be something that needs to be completely atomic. you have hundreds or thousands of files to fix. that is unreviewable as a single commit, but as a per-file, per-libr…

> you have hundreds or thousands of files to fix. that is unreviewable as a single commit, but as a per-file, per-library, per-oncall, etc. commit it is not that bad Why is it intrinsically unreviewable as a single commit? Why can't the discussion/review system allow scoping discussions to a single folder of the change, or a single library, or a particular code-owner's "slice" of the repo, etc? The answer to this que…

Why do you insist on a different but functionally equivalent solution to the problem?

It's weird.

> Why do we tolerate the fact that GitHub doesn't let you say "approved for changes in `frontend/*`

That's literally what stacked PRs are adding.

Re: GitHub Stacked PRs

#492

Post by alwillis »

Ericson2314 wrote: post #476
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...

Sapling and JJ can sort it out, the outside world will only care for one of them.

> Sapling and JJ can sort it out, the outside world will only care for one of them.

I was immediately intrigued when I learned that JJ has revsets [1], just like Mercurial.

[1]: https://docs.jj-vcs.dev/latest/revsets/

Re: GitHub Stacked PRs

#493

Post by qsera »

windward wrote: post #468
qsera wrote: post #460

Earlier quoted context omitted.

Mercurial's model is different from Git that these things you list does not make sense there. Rebase does not make sense in Mercurial because it has the concept of fixed branches. A commit is permanently linked to the branch on which it was made. So you are supposed to use merges. Same with force-pushing.

I know. It's an opinion about how to develop that a lot of people hold - a declining proportion, mind you, like Mecurial's declining market share - and it's one that they're able to represent in Git's model, with Git's features. They're even able to do it without exposing me to it. But the same isn't true in reverse. Strictly superior? Believe me, I tried to have an open mind about it. Then one day I was getting read…

>in-model way for backing that wip up to the repo.

That is because you have this notion of a "clean history", (which IIUC prevented you from making this permanent wip commit) which in reality does not have a lot of use. For most project, "useful history" or "real history" is better than a "clean" history.

That is what mercurial caters to.

Re: GitHub Stacked PRs

#494

Post by dontlikeyoueith »

a_e_k wrote: post #377
steveklabnik wrote: post #164

Earlier quoted context omitted.

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.…

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 squ…

> 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?

Re: GitHub Stacked PRs

#495

Post by claytonjy »

pastel8739 wrote: post #163
akersten wrote: post #79

Does it fix the current UX issue with Squash & Merge? Right now I manually do "stacked PRs" like this: main If PR B merges first, PR A can merge to main no problems. If PR A merges to main first, fixing PR B is a nightmare. The GitHub UI automatically changes the "target" branch of the PR to main, but instantly conflicts spawn from nowhere. Try to rebase it and you're going to be manually looking at every non-conflic…

I agree that this is annoying and unintuitive. But I don’t see the simplest solution here, so: All you need to do is pull main, then do an interactive rebase with the next branch in your stack with ‘git rebase -i main’, then drop all the commits that are from the branch you just merged.

This is what i often do, but i have never been able to get many coworkers onboard. In my experience I’d say less than 5% of all software folk i’ve worked with are willing to do an interactive rebase; everyone else finds it too scary

Re: GitHub Stacked PRs

#496

Post by bmitc »

ezekg wrote: post #479
bmitc wrote: post #208

Earlier quoted context omitted.

Why don't you use the CLI?

Because git is all I need.

Then why are you using GitHub? :)

My point is that Git is just a component of the GitHub tool, and the GitHub CLI is quite good and helps automate many things in GitHub. For example, even just using `gh browse` and `gh pr create --web` and `gh pr view --web` are fantastic tools.

Re: GitHub Stacked PRs

#497

Post by normie3000 »

steveklabnik wrote: post #236
normie3000 wrote: post #225

Earlier quoted context omitted.

> Commits are immutable I guess this is why you're getting downvoted. Commits can be edited.

When you edit a commit, it creates a new commit. They are immutable. You can still find the old commit via the reflog, until it gets eventually gc'd. If I had to guess a reason they were downvoted (and I didn't downvote, to be clear), it's probably because people see stacked diffs as specifically solving "reviews clearly taking too long, too much content in there", and so it feels contradictory. Then again, as I said…

Thank you for the correction.

Re: GitHub Stacked PRs

#498

Post by ezekg »

bmitc wrote: post #496
ezekg wrote: post #479

Earlier quoted context omitted.

Because git is all I need.

Then why are you using GitHub? :) My point is that Git is just a component of the GitHub tool, and the GitHub CLI is quite good and helps automate many things in GitHub. For example, even just using `gh browse` and `gh pr create --web` and `gh pr view --web` are fantastic tools.

I don't need to automate anything in GitHub, I have a web browser for when I need to use GitHub. Installing and learning another CLI seems like a waste of my time for very, very little return.

Re: GitHub Stacked PRs

#499

Post by ezst »

qsera wrote: post #460
windward wrote: post #420

Earlier quoted context omitted.

Mercurial can't rebase without an extension, or force push. Are you using a definition of strictly superior that means it has fewer features?

Mercurial's model is different from Git that these things you list does not make sense there. Rebase does not make sense in Mercurial because it has the concept of fixed branches. A commit is permanently linked to the branch on which it was made. So you are supposed to use merges. Same with force-pushing.

I'd like to fill up some inaccuracies in your response:

- rebasing in Mercurial simply means chopping a subtree off of the history and re-attaching it to a different parent commit. In that sense, rebasing is a very useful and common history-rewriting operation. In fact, it's even simpler and more powerful/versatile than in git, because mercurial couldn't care less if the sub-tree you are rebasing belongs to a branch or not: it's just a DAG. It gets transplanted from A to B. A may or may not be your checked commit, or be the tip of a branch, doesn't matter.

- that mercurial requires a configuration toggle before rebasing can be used (i.e. that the user need to enable the extension explicitly) is a way to encourage interested users to learn their tool, and grow its capabilities together with their knowledge. It's opinionated, it may be too much hand-holding for some, but there is an elegant simplicity in keeping the help pages and autocomplete commands just as complex as the user can take it.

Re: GitHub Stacked PRs

#500

Post by bmitc »

ezekg wrote: post #498
bmitc wrote: post #496

Earlier quoted context omitted.

Then why are you using GitHub? :) My point is that Git is just a component of the GitHub tool, and the GitHub CLI is quite good and helps automate many things in GitHub. For example, even just using `gh browse` and `gh pr create --web` and `gh pr view --web` are fantastic tools.

I don't need to automate anything in GitHub, I have a web browser for when I need to use GitHub. Installing and learning another CLI seems like a waste of my time for very, very little return.

You would rather manually browse to the repo you're working on in the web interface rather than typing `gh browse`? I hate CLIs, in general, but the GitHub CLI has some very useful commands.
Post reply on HN