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

Stacked Diffs versus Pull Requests

jg.gg

Post reply on HN
Print view View original

11–20 of 77 posts

Re: Stacked Diffs versus Pull Requests

#11

Post by ajuc »

Isn't this basically how gerrit is supposed to be used? At least that's how we use it (but it's a very small team so anything would work I guess).

You work on master, you rebase -i your commits to make them nice to review, you push them to gerrit, someone reviews them and pushes them to master or returns with stuff to fix. You usually have a few commits on top of remote master in your local master, and when any of them is pushed to remote master from gerrit you just git fetch && git rebase.

Re: Stacked Diffs versus Pull Requests

#12

Post by Joky »

slobotron wrote: post #4
jepler wrote: post #3

I think I agree with what the author is saying, by and large, but it doesn't matter: if it's a mental model that works for you, you can live in the "stacked diffs" world right up until you need to "curate" all your commits into something that can be considered for incorporation into the parent project. Then you still need to make a branch, put all the related commits into it in order, and adequately test that branch…

Hm, I thought the idea is that the only way something will land in master is if it reviews OK and CI passes all the tests on top of the current master?

"on top of the current master" is limiting: how do you handle concurrency? I.e. two developers kicking tests on their PR on top of current master, everything green, but they merge and the result of their merge is not building (or passing tests) anymore.

Re: Stacked Diffs versus Pull Requests

#13

Post by falsedan »

petters wrote: post #6

> How do you git bisect a codebase where every 6th commit doesn’t build because it was jammed into the middle of a Pull Request? This I think is the main problem with pull requests. A better default would be squashing the commits into a single one after review.

You can start bisecting and then skip every commit on a feature branch that was merged in. Painful to script and I wish bisect had a --first-parent flag to do it for me

Re: Stacked Diffs versus Pull Requests

#14

Post by Joky »

petters wrote: post #6

> How do you git bisect a codebase where every 6th commit doesn’t build because it was jammed into the middle of a Pull Request? This I think is the main problem with pull requests. A better default would be squashing the commits into a single one after review.

Bisect on first-parent? Seems like a script exists (haven't tried): https://gist.github.com/ayust/2040290

Re: Stacked Diffs versus Pull Requests

#15

Post by jval43 »

So basically what Gerrit offers as the "cherry-pick" submit type? You work on the master branch, then push commits as changesets to Gerrit. After review they are cherry-picked by the system onto the target (master) branch, in whatever order they happened to be reviewed. Or am I missing something?

Re: Stacked Diffs versus Pull Requests

#16

Post by falsedan »

stevebmark wrote: post #10

This is very long and i'm tired, is there a more condensed resource?

I think the tl;dr is “stacked diffs require running different commands than git pull --rebase”

The author complains about wasting time branching and merging, but other examples at the end still have the same number of operations and still hit the same merge conflicts.

They make the point of how dependant work requires multiple branches but I feel it’s a workflow constraint, or a technical one. It can be easily avoided by creating branches as late as possible! Usually, when I’m working on a problem that requires multiple merges, I

1. Create a branch to fix the problem

2. Work on it

3. Rebase it so I can merge the first few commits

4. Push just those commits with a different branch name

5. Get it reviewed

6. a. Merge the reviewed branch into master and rebase the problem branch on top of master

6. b. Update the branch under review with feedback fixes, push it & update the review & rebase the problem branch onto the updated branch under review & go back to 5

7. Go back to 2

Just don’t do what I end up doing on personal projects and let 6 months go past between 2 and 3

Re: Stacked Diffs versus Pull Requests

#17

Post by [deleted] »

ajuc wrote: post #11

Isn't this basically how gerrit is supposed to be used? At least that's how we use it (but it's a very small team so anything would work I guess). You work on master, you rebase -i your commits to make them nice to review, you push them to gerrit, someone reviews them and pushes them to master or returns with stuff to fix. You usually have a few commits on top of remote master in your local master, and when any of th…

[deleted]

Re: Stacked Diffs versus Pull Requests

#19

Post by peterjmag »

I think GitHub's great, and I'm mostly okay with having to rely on it heavily at my day job, but I dislike how code reviews + PRs are necessarily tied to branches.

What are the chances of GitHub introducing stacked diffs (or a similar abstraction) as an option? It'd be great to try out this workflow on a non-trivial project, but it seems like a hard sell organizationally when it involves migrating to and supporting a completely different tool like Phabricator or Gerrit.

Post reply on HN