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

281–290 of 548 posts

Re: GitHub Stacked PRs

#281

Post by eru »

outworlder wrote: post #128
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!

> The issue is solely that OG Mercurial was written in Python. Are we back to "programming language X is slow" assertions? I thought those had died long ago. Better algorithms win over 'better' programming languages every single time. Git is really simple and efficient. You could reimplement it in Python and I doubt it would see any significant slowness. Heck, git was originally implemented as a handful of low level…

> Better algorithms win over 'better' programming languages every single time.

That's often true, but not "every single time".

Re: GitHub Stacked PRs

#282

Post by byroot »

jmalicki wrote: post #265
outworlder wrote: post #128

Earlier quoted context omitted.

> The issue is solely that OG Mercurial was written in Python. Are we back to "programming language X is slow" assertions? I thought those had died long ago. Better algorithms win over 'better' programming languages every single time. Git is really simple and efficient. You could reimplement it in Python and I doubt it would see any significant slowness. Heck, git was originally implemented as a handful of low level…

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…

> every method call is a string dict lookup

Doesn't the Python VM have inline caches? [0]

https://en.wikipedia.org/wiki/Inline_caching

Re: GitHub Stacked PRs

#283

Post by eru »

jmalicki wrote: post #265
outworlder wrote: post #128

Earlier quoted context omitted.

> The issue is solely that OG Mercurial was written in Python. Are we back to "programming language X is slow" assertions? I thought those had died long ago. Better algorithms win over 'better' programming languages every single time. Git is really simple and efficient. You could reimplement it in Python and I doubt it would see any significant slowness. Heck, git was originally implemented as a handful of low level…

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 language like Python which is so defined by its dominant implementation of CPython.

Re: GitHub Stacked PRs

#284

Post by eru »

Diggsey wrote: post #198
outworlder wrote: post #128

Earlier quoted context omitted.

> The issue is solely that OG Mercurial was written in Python. Are we back to "programming language X is slow" assertions? I thought those had died long ago. Better algorithms win over 'better' programming languages every single time. Git is really simple and efficient. You could reimplement it in Python and I doubt it would see any significant slowness. Heck, git was originally implemented as a handful of low level…

> git was originally implemented as a handful of low level binaries stitched together with shell scripts. A bunch of low level binaries stitched together with shell scripts is a lot faster than python, so not really sure what the point of this comparison is. Python is an extremely versatile language, but if what you're doing is computing hashes and diffs, and generally doing entirely CPU-bound work, then it's objecti…

Well, you can and people do use Python to stitch together low level C code. In that sense, you could go the early git approach, but use Python instead of shell as the glue.

Re: GitHub Stacked PRs

#285

Post by gorgoiler »

WhyNotHugo wrote: post #124

I really don't get the point of stacked PRs. Just using git, you'd send a set of patches, which can be reviewed, tested and applied individually. The PR workflow makes a patch series an undivisible set of changes, which must be reviewed, tested and applied in unison. And stacked PRs tries to work around this issue, but the issue is how PRs are implemented in the first place. What you really want is the ability to rev…

Exactly! A stack of PRs is really the same beast as a branch of commits.

The traditional tools (mailing-lists, git branches, Phabricator) represented each change as a difference between an old version of the code and the proposed new version. I believe Phabricator literally stored the diff. They were called “diffs” and you could make a new one by copying and pasting into a before pressing save*.

The new fangled stuff (GitHub and its clones) recorded your change as being between branches A and B, showed you the difference on the fly, and let you modify branch B. After fifteen years of this we are now seeing the option for branch A to be something other than main, or at least for this to be a well supported workflow.

In traditional git land, having your change as a first class object — an email or printout or ph/D1234 with the patch included — was the default workflow!

*Or some other verb meaning save.

Re: GitHub Stacked PRs

#286

Post by illamint »

eru wrote: post #274
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…

Oh, phabricator. I hated that tool with a passion. It always destroyed my carefully curated PR branch history. See https://stackoverflow.com/questions/20756320/how-to-prevent-...

Good. That's the point.

Re: GitHub Stacked PRs

#287

Post by jmalicki »

byroot wrote: post #282
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…

> every method call is a string dict lookup Doesn't the Python VM have inline caches? [0] https://en.wikipedia.org/wiki/Inline_caching

I think that's a new thing from like python 3.12+ or something after I stopped using Python as much.

It didn't used to.

EDIT: python 3.11+: https://peps.python.org/pep-0659/

Re: GitHub Stacked PRs

#288

Post by eru »

illamint wrote: post #286
eru wrote: post #274

Earlier quoted context omitted.

Oh, phabricator. I hated that tool with a passion. It always destroyed my carefully curated PR branch history. See https://stackoverflow.com/questions/20756320/how-to-prevent-...

Good. That's the point.

The point of what?

I hope they fixed phabricator in the meantime.

Re: GitHub Stacked PRs

#289

Post by jmalicki »

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…

Fair! I guess I didn't mean language as such, but as used.

But a lot of the monkey-patching kind of things and dynamism of python also means a lot of those sorts of things have to be re-checked often for correctness, so it does take a ton of optimizations off the table. (Of course, those are rare corner cases, so compilers like pypy have been able to optimize for the "happy case" and have a slow fall-back path - but pypy had a ton of incompatibility issues and now seems to be dying).

Re: GitHub Stacked PRs

#290

Post by zmmmmm »

Curious how / how well it deals with conflicts in the different branches that are part of the stack. Is there some support for managing that, or what happens when two of the branches don't rebase / merge cleanly?
Post reply on HN