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

401–410 of 548 posts

Re: GitHub Stacked PRs

#401

Post by KptMarchewa »

adamwk wrote: post #47
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…

Maybe there’s a git trick I don’t know, but I’ve found making small branches off each other painful. I run into trouble when I update an earlier branch and all the dependent branches get out of sync with it. When those earlier branches get rebased into master it becomes a pain to update my in-progress branches as well

I understand that's what the feature is trying to solve.

Re: GitHub Stacked PRs

#402

Post by KptMarchewa »

fphilipe wrote: post #323
locknitpicker wrote: post #312

Earlier quoted context omitted.

> Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-absorb[2] and the heavy-lifting is taken care of. ...or you don't bother with all that and s…

Sure, that's possible. I can also use the GitHub app and use a Git abstraction where I don't have to understand Git at all. The point is that I want to use Git, a tool and skill that is portable to other platforms.

That's like, most AI obsoleteable skill you could pick.

Re: GitHub Stacked PRs

#403

Post by xmcqdpt2 »

eru wrote: post #283
jmalicki wrote: post #265

Earlier quoted context omitted.

Every time I've rewritten something from Python into Java, Scala, or Rust it has gotten around ~30x faster. Plus, now I can multithread too for even more speedups. Python is absurdly slow - every method call is a string dict lookup (slots are way underused), everything is all dicts all the time, the bytecode doesn't specialize at all to observed types, it is a uniquely horrible slow language. I love it, but python is…

> [...], it is a uniquely horrible slow language. To be fair, Python as implement today is horribly slow. You could leave the language the same but apply all the tricks and heroic efforts they used to make JavaScript fast. The language would be the same, but the implementations would be faster. Of course, in practice the available implementations are very much part of the language and its ecosystems; especially for a…

You don't even need to go all V8, you could just build something like LuaJIT and get most of the way there. LuaJIT is like 10k LOCs and V8 is 3M LOC.

The real reason is that it is a deliberate choice by the CPython project to prefer extensibility and maintainability to performance. The result is that python is a much more hackable language, with much better C interop than V8 or JVM.

Re: GitHub Stacked PRs

#404

Post by kasey_junk »

awesome_dude wrote: post #114
forrestthewoods wrote: post #104

Earlier quoted context omitted.

Mercurial has a strictly superior API. The issue is solely that OG Mercurial was written in Python. Git is super mid. It’s a shame that Git and GitHub are so dominant that VCS tooling has stagnated. It could be so so so much better!

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.

Re: GitHub Stacked PRs

#405

Post by Liskni_si »

gugagore wrote: post #374
AJRF wrote: post #366

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

If there is a stack of size n and you make a modification at the first change, closest to the trunk, is there a single git command you can run to rebase the other n-1 branches and ensure they remote branches are updated?

Not a single one, but it can be done with 2.

Assuming you're currently on the most recent branch (furthest from the trunk), `git rebase -i --update-refs trunk` will rebase all the intermediate branches. If you need to make a change to the first branch nearest the trunk, either use `edit` in the interactive rebase, or make a fixup commit and enable autosquash for the rebase. The `--update-refs` flag makes sure that all the intermediate branches get updated during the rebase.

Then, to push them all, something like `git push origin 'refs/heads/yourname/*'` will push all branches prefixed with `yourname/`. It's a bit stupid that one can't just do `git push 'yourname/*'` though.

Re: GitHub Stacked PRs

#408

Post by littlecranky67 »

smallmancontrov wrote: post #70
adamwk wrote: post #25

As someone who used phabricator and mercurial, using GitHub and git again feels like going back to the stone ages. Hopefully this and jujutsu can recreate stacked-diff flow of phabricator. It’s not just nice for monorepos. It makes both reviewing and working on long-running feature projects so much nicer. It encourages smaller PRs or diffs so that reviews are quick and easy to do in between builds (whereas long pull…

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 might be the outlier, but am I the only one who doesn't care much about the speed of git? I've been using git since 2011 as my main vcs for personal and professional work as a freelancer contractor. Whenever I "wait" for git, it is either limited by the bandwidth (git clone) or by the amount of commit hooks that I implemented for linting, verification etc. The percentage of time actually spent in git internal execution must be a tiny fraction of my day to day usage. What IS affecting me (and my the teams I work in) is usability and UX experience. I.e. if people would screw up stuff (no matter if in git or mercurial) we spent far more time fixing this - I don't think the impmentation speed would matter here.

The only case I can imagine is when doing a full checkout of a big repo, but even there, there is --depth which is quite practical.

Re: GitHub Stacked PRs

#409

Post by Liskni_si »

atq2119 wrote: post #98

People have been building stacked PR workflows on top of GitHub for a while now. It's great to see that the message seems to have finally landed at GitHub, but what is actually new here in GitHub itself (i.e., not counting the gh CLI tool)? There seems to be a native stack navigation widget on the PR page, which is certainly a welcome addition. The most important question though is whether they finally fixed or are g…

They haven't fixed the fork issue, the FAQ clarifies this. I suspect the target audience is squash merging corpos. Everyone else can just do normal PRs with atomic commits reviewed individually...

Re: GitHub Stacked PRs

#410

Post by bonzini »

hypeatei wrote: post #398
dwattttt wrote: post #379

Earlier quoted context omitted.

GNU Bazaar thoroughly lost, last release was 2016, Canonical retired it last year: https://en.wikipedia.org/wiki/GNU_Bazaar

GP is taking about this[0] but it's quite hilarious that a VCS exists with that name. 0: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

It's not a coincidence, it was called like that as a reference to facilitating distributed development.
Post reply on HN