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

351–360 of 548 posts

Re: GitHub Stacked PRs

#351

Post by LordDragonfang »

jorams wrote: post #348
awesome_dude wrote: post #114

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?

So far you've only gotten responses to "how can a worse product win?", and they are valid, but honestly the problem here is that Mercurial is not a better product in at least one very important way: branches. You can visit any resource about git and branches will have a prominent role. Git is very good at branches. Mercurial fans will counter by explaining one of the several different branching options it has availab…

This is so strange, because, at a low level, a branch isn't even a "thing" in git. There is no branch object type in git, it's literally just a pointer to a commit, functionally no different from a tag except for the commands that interact with it.

Re: GitHub Stacked PRs

#352

Post by boomlinde »

IME the github workflow promotes bad commit hygiene by making squashing or rebasing as-is an either-or choice in the web GUI.

This will help some since you can more easily split PRs into units that make sense to squash at the end, but it still seems like not doing this on a per-commit basis is a disadvantage compared to Gerrit. With Gerrit I can use all the built-in Git rebase/squash/fixup tools to manage the commit stack and push everything in one go. I don't think there's a nearly as convenient a way to work with stacked branches in Git.

Re: GitHub Stacked PRs

#353

Post by bonesss »

kuschku wrote: post #197
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…

I've rewritten a python tool in go, 1:1. And that turned something that was so slow that it was basically a toy, into something so fast that it became not just usable, but an essential asset. Later on I also changed some of the algorithms to faster ones, but their impact was much lower than the language change.

I don’t know if people think this way anymore, but Python gained traction to some degree as a prototyping language. Verify the logic and structures, then implement the costly bits or performance sensitive bits in a more expense-to-produce more performant language.

Which is only to say: that rewrite away from python story can also work to show python doing its job. Risk reduction, scaffolding, MVP validation.

Re: GitHub Stacked PRs

#354

Post by eru »

saghm wrote: post #346
eru wrote: post #284

Earlier quoted context omitted.

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.

Their point was that by offloading the bottlenecks to C, you've essentially conceded that Python isn't fast enough for them, which was the original point made above

Fair point!

Re: GitHub Stacked PRs

#355

Post by Gabrys1 »

alwillis wrote: post #344
smallmancontrov wrote: post #70

Earlier 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*†‡" 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'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...

Re: GitHub Stacked PRs

#356

Post by rtpg »

jenadine wrote: post #66

I might be missing something, but what I need is not "stacked PR" but a proper UI and interface to manage single commit: - merge some commits independently when partial work is ready. - mark some commit as reviewed. - UI to do interactive rebase and and squash and edit individual commits. (I can do that well from the command line, but not when using the GitHub interface, and somehow not everyone from my team is famil…

yeah interdiffing and being able to cherrypick in a review just there and getting it done is nice.

Perhaps a future iteration of this feature will at least allow us to do something like merge just steps of it if they can be reordered.

Re: GitHub Stacked PRs

#359

Post by inejge »

surajrmal wrote: post #335
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…

You must belong to the club of folks who use hashmaps to store 100 objects. It's amazing how much we've brainwashed folks to focus on algorithms and lose sight of how to actually properly optimize code. Being aware of how your code interacts with cache is incredibly important. There are many cases of using slower algorithms to do work faster purely because it's more hardware friendly. The reason that some more modern…

> You must belong to the club of folks who use hashmaps to store 100 objects.

Apparently I belong to the same club -- when I'm writing AWK scripts. (Arrays are hashmaps in a trenchcoat there.) Using hashmaps is not necessarily an indictment you apparently think it is, if the access pattern fits the problem and other constraints are not in play.

> It's amazing how much we've brainwashed folks to focus on algorithms and lose sight of how to actually properly optimize code. Being aware of how your code interacts with cache is incredibly important.

By the time you start worrying about cache locality you have left general algorithmic concerns far behind. Yes, it's important to recognize the problem, but for most programs, most of the time, that kind of problem simply doesn't appear.

It also doesn't pay to be dogmatic about rules, which is probably the core of your complaint, although unstated. You need to know them, and then you need to know when to break them.

Re: GitHub Stacked PRs

#360

Post by CrimsonRain »

aaronbrethorst wrote: post #188
forrestthewoods wrote: post #141

Earlier quoted context omitted.

Worse products win all the time. Inertia is almost impossible to overcome. VHS vs Betamax is a classic. iPod wasn’t the best mp3 player but being a better mp3 player wasn’t enough to claw market share. Google and Meta don’t use Git and GitHub. Sapling and Phabricator much much better (when supported by a massive internal team)

What was the better mp3 player than the iPod?

anything from Cowon. Always has been
Post reply on HN