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

21–30 of 77 posts

Re: Stacked Diffs versus Pull Requests

#21

Post by IshKebab »

This is silly. I use Phabricator and I don't commit my changes directly to `master`. I always make a branch, exactly the same as you would for pull requests. And I have multiple commits on that branch.

Why? Firstly it means I can still pull master and rebase my changes to update them fairly easily. Secondly it means I can work on more than one thing at a time (who only ever has one task in progress?), thirdly it means I can reorganise my commits easier (`git rebase -i master`), and finally having a change split into several commits can make code review easier.

As far as I can tell the only significant difference between these two approaches is that with `arc` the history in the repository ends up nice and linear, without loads of branches.

Re: Stacked Diffs versus Pull Requests

#23

Post by kzrdude »

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.

As others have pointed out indirectly, git bisect is designed with the patch stack in mind and could be made to support pull requests better.

Re: Stacked Diffs versus Pull Requests

#24

Post by donatj »

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.

I have always been of the mind that every commit should be a working state. My coworkers who often commit with the message “WIP” disagree. I doubt I’ll ever sell them on it.

Re: Stacked Diffs versus Pull Requests

#26

Post by lima »

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…

Yes, the Phabricator and Gerrit workflows are very similar.

It's basically the same workflow the Linux kernel uses, with Phabricator or Gerrit taking the place of git format-patch and git apply-patch.

Re: Stacked Diffs versus Pull Requests

#27

Post by lima »

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…

The Phabricator project itself uses two branches - a fast-moving master and a stable branch. Changes are commited to master and then promoted to stable.

Cherry-picking patches is a lot easier when the development team submits to a "one commit per idea" and "review single commits" workflow.

Re: Stacked Diffs versus Pull Requests

#28

Post by lima »

peterjmag wrote: post #19

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…

You can do stacked diffs on GitHub by always using squash merges and rebasing on top of master, and it's a great way to get started.

It's just a lot nicer with the extra tooling on top that Phabricator and Gerrit provide (dependencies, command line tools, and so on).

Re: Stacked Diffs versus Pull Requests

#29

Post by TomK32 »

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

This is also suboptimal. I’d rather each commit be an atomic unit: no larger and no smaller than it needs to be. Edit: in other words, concurring with TFA.

yes, but often on a feature branch you have WIP, change your code a few commits later and so on. I use rebase -i a lot and it make better code.

Re: Stacked Diffs versus Pull Requests

#30

Post by [deleted] »

ghayes wrote: post #9
pbh101 wrote: post #7

Earlier quoted context omitted.

This is also suboptimal. I’d rather each commit be an atomic unit: no larger and no smaller than it needs to be. Edit: in other words, concurring with TFA.

Sure, but the best way to get there in my mind is `rebase -i`, which means you've made a few and revised a few commits along the way.

[deleted]
Post reply on HN