Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reinventing the pull request

lubeno.dev

Post reply on HN
Print view View original

91–96 of 96 posts

Re: Reinventing the pull request

#91

Post by fl0ki »

eviks wrote: post #90
fl0ki wrote: post #87

Earlier quoted context omitted.

If that's the kind of UX you prefer, please consider filing a feature request against your git UI of choice. My point is that git itself already has the core capability, and how convenient it is to use usually depends on your editor. (e.g. in vim, dd to cut a line and p to paste it in a new position is a very quick way to reorder)

And my point is that all this 'core capability' stuff is not relevant to the discussion of good UI, similarly the fact that GitHub has Pull Requests doesn't help when it's bad UI that needs "stack" reinventing. Case in point: > dd to cut a line and p to paste it in a new position is a very quick way to reorder) It isn't quick, you're just swiping the whole issue under the rug - first, you need the whole separate inte…

Like I said, if you prefer an integrated graphical UI, you can file feature requests against the one you prefer. What git itself does makes a lot of sense for the canonical CLI tool to do, though even then you can propose or prototype changes if you have ideas. This is how projects like jj started in the first place.

Re: Reinventing the pull request

#92

Post by NooneAtAll3 »

codexb wrote: post #38
petcat wrote: post #4

> Once you have the power to do a bunch of small self-contained changes, you want PRs to consist of one or two commits. You want to build on previous changes without needing to wait for them to be reviewed. Lubeno helps you to do exactly this. Why would I want to build on changes that haven't been reviewed and accepted? That's a good way to waste my time having to redo something because the foundation it was based on…

Because those changes might depend on those other changes. Git merges aren't linear. They're branched. And PR reviews are meant to just examine the merge of 1 branch back into master. They're not really meant to review multiple steps along the same branch to make it easier to review. There are so many times where I want to create 3-4 Merge requests that all build on each other along the same branch instead of creatin…

> There are so many times where I want to create 3-4 Merge requests that all build on each other instead of creating one giant MR but the UI for reviewing them doesn't really work that way.

it sounds like you want multiple checkpoints for review parts to happen on, but still only 1 merge in the end

Re: Reinventing the pull request

#93

Post by justinclift »

IshKebab wrote: post #89
justinclift wrote: post #88

Earlier quoted context omitted.

When the base and PR branch are in different repos, it'll still work if the PR branch's repo is a fork of the base one.

No it doesn't. Here's the situation. You have an upstream repo github.com/fancyproject/fancyproject. You fork it to github.com/yourname/fancyproject. You make a branch `feature_0`, push it to yourname/fancyproject. Make a PR. Next you create another branch `feature_1`, based on `feature_0`. You push `feature_1` to yourname/fancyproject. There is now no way to make a PR for `feature_1` that includes only the changes f…

Interesting.

Are you're saying that you'd want the commits for `feature_0` through `feature_1` to be in the PR (to the upstream fancyproject repo), and you'd want it to exclude the commits in the range from the fork commit through to `feature_0`?

While that's a very edge case scenario, I think (theoretically) you'd be able to do it if you first cherry-pick the commits you want onto a new branch based upon the same original fork commit that your repo forked from.

ie ensure the PR branch you create doesn't include any commits you want excluded

That should pretty much guarantee the PR goes smoothly. In theory. :)

Re: Reinventing the pull request

#94

Post by jmalicki »

justinclift wrote: post #93
IshKebab wrote: post #89

Earlier quoted context omitted.

No it doesn't. Here's the situation. You have an upstream repo github.com/fancyproject/fancyproject. You fork it to github.com/yourname/fancyproject. You make a branch `feature_0`, push it to yourname/fancyproject. Make a PR. Next you create another branch `feature_1`, based on `feature_0`. You push `feature_1` to yourname/fancyproject. There is now no way to make a PR for `feature_1` that includes only the changes f…

Interesting. Are you're saying that you'd want the commits for `feature_0` through `feature_1` to be in the PR (to the upstream fancyproject repo), and you'd want it to exclude the commits in the range from the fork commit through to `feature_0`? While that's a very edge case scenario, I think (theoretically) you'd be able to do it if you first cherry-pick the commits you want onto a new branch based upon the same or…

> Are you're saying that you'd want the commits for `feature_0` through `feature_1` to be in the PR (to the upstream fancyproject repo), and you'd want it to exclude the commits in the range from the fork commit through to `feature_0`?

That's what stacked PRs are

You can review just the addition, knowing what it is building on top of.

Re: Reinventing the pull request

#95

Post by eviks »

fl0ki wrote: post #91
eviks wrote: post #90

Earlier quoted context omitted.

And my point is that all this 'core capability' stuff is not relevant to the discussion of good UI, similarly the fact that GitHub has Pull Requests doesn't help when it's bad UI that needs "stack" reinventing. Case in point: > dd to cut a line and p to paste it in a new position is a very quick way to reorder) It isn't quick, you're just swiping the whole issue under the rug - first, you need the whole separate inte…

Like I said, if you prefer an integrated graphical UI, you can file feature requests against the one you prefer. What git itself does makes a lot of sense for the canonical CLI tool to do, though even then you can propose or prototype changes if you have ideas. This is how projects like jj started in the first place.

How does bad UI make a lot of sense?
Post reply on HN