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

411–420 of 548 posts

Re: GitHub Stacked PRs

#411

Post by [deleted] »

awesome_dude wrote: post #167
guelo wrote: post #132

Earlier quoted context omitted.

Network effects and marketing can easily prevent better tools from winning.

I mean, in the fickle world that is TECH, I am struggling to believe that that's what's happened. I personally went from .latest.latest.latest.use.this (naming versions as latest) to tortoise SVN (which I struggled with) to Git (which I also was one of those "walk around with a few memorised commands" people that don't actually know how to use it) to reading the fine manual (well 2.5 chapters of it) to being an evang…

[deleted]

Re: GitHub Stacked PRs

#412

Post by Izkata »

arw0n wrote: post #372
awesome_dude wrote: post #167

Earlier quoted context omitted.

I mean, in the fickle world that is TECH, I am struggling to believe that that's what's happened. I personally went from .latest.latest.latest.use.this (naming versions as latest) to tortoise SVN (which I struggled with) to Git (which I also was one of those "walk around with a few memorised commands" people that don't actually know how to use it) to reading the fine manual (well 2.5 chapters of it) to being an evang…

Networking effects are significantly strengthened by necessary user buy in. VC is hard, and every tool demands its users to spend a non-significant amount of time learning it. I would guess the time to move from black magic to understanding most of git is ~100h for most people. The thing is, to understand which one is actually better, you would have to give the same amount of investment in the second tool, which is n…

A little over a decade ago, with only svn experience, I tried both mercurial and git. There was something about how mercurial handled branches that I found extremely confusing (don't remember what), while git clicked immediately - even without reading the manual.

So at least for me, git was clearly better.

Re: GitHub Stacked PRs

#413

Post by Phlogistique »

akersten wrote: post #79

Does 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…

I made a tool that adresses this precise problem: https://github.com/scortexio/autorestack-action/

It does some merge magic so that PR B shows the correct diff; and does so without needing to force push, so on your side you can just "git pull" and continue working.

Of course I expect this repo to become obsolete when GitHub makes their native stacking public.

Re: GitHub Stacked PRs

#414

Post by Cthulhu_ »

bmitc wrote: post #205
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.

Git is not remotely fast for large projects.

Define "large"; I've never ran into serious performance issues during the ~15 years I've used Git, which either means the projects I've worked in aren't actually large large, or Git is fast enough for most use cases.

Re: GitHub Stacked PRs

#415

Post by rstuart4133 »

skydhash wrote: post #267
MrJohz wrote: post #180

Earlier quoted context omitted.

I find rebases are only a footgun because the standard git cli is so bad at representing them - things like --force being easier to write than --force-with-lease, there being no way to easily absorb quick fixes into existing commits, interdiffs not really being possible without guesswork, rebases halting the entire workflow if they don't succeed, etc. I've switched over pretty much entirely to Jujutsu (or JJ), which…

The magic of the git cli is that it gives you control. Meaning whatever you want to do can be done. But it only gives you the raw tools. You'll need to craft your own workflow on top of that. Everyone's workflow is different. > So while I'm working on my branch, I can iteratively make a[...]which means git blame tends to be much more accurate and helpful Everything here I can do easily with Magit with a few keystroke…

> But there's the reflog in git which is the ultimate undo tool.

That one sentence outs you as someone who isn't familiar with JJ.

Here is something to ponder. Despite claims to the contrary, there are many git commands that can destroy work, like `git reset --hard`. The reflog won't save you. However there is literally no JJ command that can't be undone. So no JJ command will destroy your work irretrievably.

Re: GitHub Stacked PRs

#416

Post by krick »

xmcqdpt2 wrote: post #400
jorams wrote: post #348

Earlier quoted context omitted.

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…

It's interesting that branches, which is a marquee feature of git, became less important at the same time as git ate all the other vcs. Outside of OS projects, almost all development is trunk based with continuous releases. Maybe branching was an important reason to adopt git but now we'd probably be ok with a vcs that doesn't even support them.

Not sure if it's true. I mean, I do agree with the core of it, but how do you even do PRs and resolve conflicts, if there are no branches and a developer cannot efficiently update his code against the last (remote) version of master branch?

Re: GitHub Stacked PRs

#417

Post by skydhash »

akersten wrote: post #337
skydhash wrote: post #272

Earlier quoted context omitted.

> the "update branch" button for PR B is grayed out because there are these hallucinated conflicts due to the new squash commit Those are not hallucinated. PR B still contains all the old commits of A which means merging would apply them twice. The changes in PR B are computed according to the oldest commits belonging to PR B and main which is the parent of squashed A. That would essentially means applying A twice wh…

I guess to me, I'm looking at it from the perspective of diffing the repo between the squashed commit on main and the tip of the incoming PR. If there are merge conflicts during the rebase in files that don't appear in that diff , I consider that a hallucination, because those changes must already in the target branch and no matter what happened to those files along the way to get there, it will always be a waste of…

You’re looking at it from the perspective of a human reasoning. But a computer is a simple machine (what it can do, not how it does it). What seems obvious to you could be a complicated algorithm.

Git store all its information as a directed acyclic graph (a tree) of commits. The leaves of that tree have names, and are what we called branches. Each commit points to a tree (also a tree data structure) where the nodes are blobs (files) and sub trees. But that tree only stores the files that has been changed since the last commit. Git does not store diffs. Diffs are computed as needed.

This why the common ancestor commit is important. From there, a version of the working directory is computed for each branch (main-with-squashed-A and PR B). Files that have not been changed since PR A are ok, but everything else will be different, especially if you’ve modified the same lines.

Squashed A is a brand new commit with a new tree that PR B does not know about. You need to recompute PR B on top of Squashed A, (which will create new commits for PR B).

Re: GitHub Stacked PRs

#418

Post by [deleted] »

adityaathalye wrote: post #334
kardianos wrote: post #32

Earlier quoted context omitted.

I continue to use gerrit explicitly because I cannot stand github reviews. Yes, in theory, make changes small. But if I'm doing larger work (like updating a vendored dep, that I still review), reviewing files is... not great... in github.

Same team, and a rare hill I'm willing to die on. Rant incoming... Boy do I hate Github/Lab/Bucket style code reviews with a burning passion. Who the hell loses code review history? A record of the very thing that made my code better? The "why" of it all, that I am guaranteed to forget tomorrow morning. Nobody would be using `--force` or `--force-with-lease` as a normal part of development workflow, of their own voli…

[deleted]

Re: GitHub Stacked PRs

#419

Post by windward »

littlecranky67 wrote: post #408
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 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 execu…

Isn't it kind of like how you don't care much about the oxygen content of the air around you, but you'd miss it if it was gone? I've done development with Mercurial, simple processes were irritatingly slow, particularly if you stray from the better-supported opinionated path.

Re: GitHub Stacked PRs

#420

Post by windward »

forrestthewoods wrote: post #104
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.

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!

Mercurial can't rebase without an extension, or force push. Are you using a definition of strictly superior that means it has fewer features?
Post reply on HN