Earlier quoted context omitted.
Maybe forgejo has a shot?
Unfortunatly out-of-the-box llm agents only focus on github support, creating friction.
So pi.dev + forgejo?
GitHub Stacked PRs
361–370 of 548 posts
Re: GitHub Stacked PRs
#362Earlier 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-lfs exists for a while now. Does that fix your issue? Or do you mean that it doesn’t support binary diffs?
Git LFS is a gross hack that results in pain and suffering. Effectively all games use Perforce because Git and GitLFS suck too much. It’s a necessary evil.
Re: GitHub Stacked PRs
#363[dead]
Re: GitHub Stacked PRs
#364[dead]
Re: GitHub Stacked PRs
#365Earlier 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". 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…
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.
Re: GitHub Stacked PRs
#366I have never got a good answer to "can't you just make smaller PRs". This is convoluted tooling (needs its own CLI) for something you could achieve with just learning how git works.
Re: GitHub Stacked PRs
#367First thing that came to mind was git butler.
Re: GitHub Stacked PRs
#368I have never got a good answer to "can't you just make smaller PRs". This is convoluted tooling (needs its own CLI) for something you could achieve with just learning how git works.
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.
Re: GitHub Stacked PRs
#369Earlier quoted context omitted.
What is kind of funny here is that you're right locally. At the same time, the larger tech companies (Meta and Google, specifically) ended up building off of hg and not git because (at the time, especially) git cannot scale up to their use cases. So while the git CLI was super fast, and the hg CLI was slow, "performance" means more than just CLI speed. I was never a fan of hg either, but now I can use jj, and get som…
>At the same time, the larger tech companies (Meta and Google, specifically) ended up building off of hg and not git because (at the time, especially) git cannot scale up to their use cases. Fun story: I don't really know what Microsoft's server-side infra looked like when they migrated the OS repo to git (which, contrary to the name, contains more than just stuff related to the Windows OS), but after a few years the…
So 30 odd years later, MS went from working on OS/2 to working on OS2?
I guess what's old is new again.
Re: GitHub Stacked PRs
#370Does 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…
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