Live data from Hacker News

GitHub Stacked PRs

github.github.com

541–548 of 548 posts

Re: GitHub Stacked PRs

#541

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.

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

I get your sentiment, but I know how working with e.g. SVN feels. Just doing "svn log" was a pain when I had to do it. The "distributed" aspect of DVCS doesn't prevent you from keeping central what you need central. E.g. you can have github or your own hosting server that your team is exchanging through.

The main point of distributed is speed and self-sufficiency which is a huge plus. E.g. occasional network outages and general lack of bandwidth are still a thing in 2026 (and remain so to some extent for the foreseeable future).

Now, could git improve and allow some things to be staged/tiered/transparently cached better? Probably, and that's where some things like LFS come in. I don't have a large amount of experience in this field though, because what I work with is adequately served by the out-of-the-box git experience.

Re: GitHub Stacked PRs

#542
post #493

Earlier quoted context omitted.

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

Everything that I say is my opinion. I don't parrot consensus.

Re: GitHub Stacked PRs

#543

Earlier quoted context omitted.

Whatever your opinion on one tool or another might be - it does seem weird that the "market" has been captured by what you are saying is a lesser product. IOW, what do you know that nobody else does?

GitHub had a business model where public repos were free. BitBucket didn’t. That’s it. That’s why git won, you could put up open source libs with one for free and not the other. Which is extra funny as the centralized service was the most important part of decentralized version control.

Apologies for the late reply - but I just saw this and immediately thought

So git /did/ have something better than Mercurial after all, it was a 3rd party, but it still meant that it was massively better than Mercurial.

Re: GitHub Stacked PRs

#544

Earlier quoted context omitted.

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!

Ha, yeah, of course I know too! I should have said it different, I meant other people were talking about needing this feature for very large teams, but I find it's needed for very small teams for perhaps different reasons related to their smallness! I need to stack PR's because I need to keep writing on top of the completed PR(s) but it might be a few days until someone else can get to reviewing because there are only a few of us and we're all doing everything.
Post reply on HN