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

531–540 of 548 posts

Re: GitHub Stacked PRs

#531

Post by marktani »

jrochkind1 wrote: post #122
tcoff91 wrote: post #75

Earlier quoted context omitted.

It's basically trying to bring the stacked diff workflow pioneered by Phabricator to GitHub. The idea is that it allows you to better handle working on top of stuff that's not merged yet, and makes it easier for reviewers to review pieces of a larger stack of work independently. It's really useful in larger corporate environments. I've used stacked PRs when doing things like upgrading react-native in a monorepo. It r…

I'm not in a large corporate environment, but that also means we're not always a well oiled machine, and sometimes i am writing faster than the reviewer can review for a period of time -- and i really need the stacking then too.

> I'm not in a large corporate environment, but that also means we're not always a well oiled machine

haha, I'm sitting in a very crusty corporate environment right now and your comment made me chuckle. I get where you're coming from though, of course!

Re: GitHub Stacked PRs

#532

Post by hambes »

scaryclam wrote: post #384
hambes wrote: post #368

Earlier quoted context omitted.

I agree that a `gh stack` command is not needed, but this feels to me like just a better UI feature for a good git workflow. It literally is about making multiple smaller PRs that build on top of each other.

The question is, why are you not just merging them into main as you go? It's a bit of a smell when you "need" to merge branches into branches. It shows a lack of safety and ease in deployments, which is the real problem to solve IMO.

because approval processes take time which i can use to keep working

Re: GitHub Stacked PRs

#533

Post by forrestthewoods »

jstimpfle wrote: post #392
forrestthewoods wrote: post #212

Earlier quoted context omitted.

The fact that Git has an extremely strong preference for storing full and complete history on every machine is a major annoyance! “Except for network IO” is not a valid excuse imho. Cloning the Linux kernel should take only a few seconds. It does not. This is slow and bad. The mere fact that Git is unable to handle large binary files makes it an unusable tool for literally every project I have ever worked on in my en…

git clone --bare --depth=1 https://github.com/torvalds/linux Takes 21 seconds on my work laptop, indeed a corporate Windows laptop with antivirus installed. Majority of that time is simply network I/O. The cloned repository is 276 MB large. Actually checking the kernel out takes 90 seconds. This amounts to creating 99195 individual files, totaling 2 GB of data. Expect this to be ~10 times faster on a Linux file syste…

—-depth=1 is a hack and breaks assorted things. It’s irritating. No I can’t tell you what random rakes I’ve stepped on in the past because of this. Yes they still exist.

If you’d like to argue that version control should be centralized, shallow, and sparse by default then I agree.

Re: GitHub Stacked PRs

#534

Post by eptcyka »

adregan wrote: post #244
eptcyka wrote: post #100

Earlier quoted context omitted.

What if main/master moves in between reviews?

You head to the farthest branch in the chain, fetch the latest main, and run `git rebase --update-refs main` (I prefer interactive mode myself) and then force push all of the branches from start to the end. 1: https://git-scm.com/docs/git-rebase#Documentation/git-rebase...

I know what one does manually, but how does stack make decisions here when there’s a conflict? The reason we use a rebase flow is to allow for adjusting commits that are no longer valid.

Re: GitHub Stacked PRs

#535

Post by jstimpfle »

forrestthewoods wrote: post #533
jstimpfle wrote: post #392

Earlier quoted context omitted.

git clone --bare --depth=1 https://github.com/torvalds/linux Takes 21 seconds on my work laptop, indeed a corporate Windows laptop with antivirus installed. Majority of that time is simply network I/O. The cloned repository is 276 MB large. Actually checking the kernel out takes 90 seconds. This amounts to creating 99195 individual files, totaling 2 GB of data. Expect this to be ~10 times faster on a Linux file syste…

—-depth=1 is a hack and breaks assorted things. It’s irritating. No I can’t tell you what random rakes I’ve stepped on in the past because of this. Yes they still exist. If you’d like to argue that version control should be centralized, shallow, and sparse by default then I agree.

Then just do git pull --unshallow whenever you see fit. I normally don't do --depth 1 because cloning repositories is rarely my bottleneck. Just saying that when you need a relatively fast clone time, you can have it.

Re: GitHub Stacked PRs

#536

Post by jstimpfle »

ezst wrote: post #503
fc417fc802 wrote: post #388

Earlier quoted context omitted.

Meanwhile mercurial has bookmarks. TBF I'm not sure when it got those but they've been around forever at this point. The purpose is served. I think there are (or perhaps were) some product issues regarding the specifics of various workflows. But at least some of that is simply the inertia of entrenched workflows and where there are actual downsides the (IMO substantial) advantages need to be properly weighed against…

> I think there are (or perhaps were) some product issues regarding the specifics of various workflows. I love jumping in discussions about git branching, because that's a very objective and practical area where git made the playing field worse. Less and less people feel it, because people old-enough to have used branch-powered VCSes have long forgotten about them, and those who didn't forget are under-represented in…

Just because there is one project apparently using this in a way that indicates someone could perceive something as a weakness... It doesn't mean it's a real weakness (nor that it's serious).

You can just not move branches. But once you can do it, you will like it. And you are going to use

   git branch --contains COMMIT
which will tell you ALL the branches a commit is part of.

Git's model is clean and simple, and makes a whole lot of sense. IMHO.

Re: GitHub Stacked PRs

#537

Post by jstimpfle »

ezst wrote: post #503
fc417fc802 wrote: post #388

Earlier quoted context omitted.

Meanwhile mercurial has bookmarks. TBF I'm not sure when it got those but they've been around forever at this point. The purpose is served. I think there are (or perhaps were) some product issues regarding the specifics of various workflows. But at least some of that is simply the inertia of entrenched workflows and where there are actual downsides the (IMO substantial) advantages need to be properly weighed against…

> I think there are (or perhaps were) some product issues regarding the specifics of various workflows. I love jumping in discussions about git branching, because that's a very objective and practical area where git made the playing field worse. Less and less people feel it, because people old-enough to have used branch-powered VCSes have long forgotten about them, and those who didn't forget are under-represented in…

> Less and less people feel it, because people old-enough to have used branch-powered VCSes have long forgotten about them, and those who didn't forget are under-represented in comparison to the newcomers who never have experienced anything else since git became a monopoly.

I'm old enough to have used SVN (and some CVS) and let me tell you branching was no fun, so much that we didn't really do it.

Re: GitHub Stacked PRs

#538

Post by ezst »

qsera wrote: post #517
ezst wrote: post #499

Earlier quoted context omitted.

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…

> rebasing in Mercurial simply means chopping... Sure, but since commits have a branch attribute attached to them, "rebasing" does not appear to be "first class". It is something that has to be bolted on with an extension. > because mercurial couldn't care less if the sub-tree you are rebasing belongs to a branch or not IIUC Git also does not care much about the rebase target being a "branch". I agree that Mercurial…

> Sure, but since commits have a branch attribute attached to them, "rebasing" does not appear to be "first class".

Again, that's orthogonal: you may or may not use "named branches" (the kind of which persists at commit level), rebasing works either way consistently and predictably.

> It is something that has to be bolted on with an extension.

The extension ships in core, UX is why it's not enabled by default.

> IIUC Git also does not care much about the rebase target being a "branch".

Indeed, it's just that things likely get weird (for no good reason) when you don't (detached head, "unreachable" commits)

> I can live with Git because Git is "enough" if used carefully and after coming to terms with the non-intutive UI.

That's our sad state of affairs. JJ helps a bit, though.

Re: GitHub Stacked PRs

#539

Post by windward »

qsera wrote: post #493
windward wrote: post #468

Earlier quoted context omitted.

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.

>For most project, "useful history" or "real history" is better than a "clean" history.

This is your opinion, so I'm compelled to point out it's not the consensus opinion.

Re: GitHub Stacked PRs

#540

Post by windward »

ezst wrote: post #501
windward wrote: post #468

Earlier quoted context omitted.

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…

> 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? not sure what you mean to say, but for thoroughness' sake, no: git and mercurial concepts are not interchangeable, with git having mostly an inferior model. To give examples: git has no concept of branching (in the way every VCS but Git…

>If you want your WIP changes to leave your laptop, you've got to push them somewhere, just like you would in git.

Permanently, to a single branch in un-buildable form. So useful.

Post reply on HN