3 ms·

The piece seems to make the most negative assumptions about one workflow and the most optimistic ones about the other. Or rather the assumption that you take th

The piece seems to make the most negative assumptions about one workflow and the most optimistic ones about the other. Or rather the assumption that you take the effort to learn the optimal way to use one workflow but take no effort to do the same for the other. Most everything looks great when you take that approach. Things like making a branch off of another branch being somehow so difficult that no one would ever even consider it. Or that there isn't a Github CLI tool that allows you to avoid having to go to the UI.

vlovich123 6y ago
Speaking from personal experience I’ve done both. The “optimal” PR experience is still more painful than stacked diffs if you’re working on a team that cares about commit quality (which everyone should IMO)
- sweeneyrod 6y ago
  If you care about having nice self-contained commits, what is your process for sending rough work-in-progress to colleagues, or to continuous integration?
  - Game_Ender 6y ago
    You post PRs in a draft or WIP state and don’t request review until you are ready. This lets you leverage CI, but not take any time away from others who are doing review.
  - vlovich123 6y ago
    same in both cases. Either you put up a PR or a stack set with no reviewers and send that to whoever needs it. In the stack diff approach you can actually add reviewers for the “non controversial” parts that are ready for review and not add reviewers to the ones that aren’t ready yet. In both cases you can rewrite your commit stack after-the-fact to add new ones, make fixes etc.
- marcinzm 6y ago
  Which is a valid argument imho, I just found the article to make too many pessimistic/optimistic assumptions based on the workflow they dislike/like.
chrisweekly 6y ago
Good points. > "a Github CLI tool that allows you to avoid having to go to the UI." -- better yet, git-extras (https://github.com/tj/git-extras https://github.com/tj/git-extras) provides CLI utils that work across github, gitlab, and bitbucket.

vlovich123 6y ago

Speaking from personal experience I’ve done both. The “optimal” PR experience is still more painful than stacked diffs if you’re working on a team that cares about commit quality (which everyone should IMO)

sweeneyrod 6y ago
If you care about having nice self-contained commits, what is your process for sending rough work-in-progress to colleagues, or to continuous integration?
- Game_Ender 6y ago
  You post PRs in a draft or WIP state and don’t request review until you are ready. This lets you leverage CI, but not take any time away from others who are doing review.
- vlovich123 6y ago
  same in both cases. Either you put up a PR or a stack set with no reviewers and send that to whoever needs it. In the stack diff approach you can actually add reviewers for the “non controversial” parts that are ready for review and not add reviewers to the ones that aren’t ready yet. In both cases you can rewrite your commit stack after-the-fact to add new ones, make fixes etc.
marcinzm 6y ago
Which is a valid argument imho, I just found the article to make too many pessimistic/optimistic assumptions based on the workflow they dislike/like.

chrisweekly 6y ago

Good points. > "a Github CLI tool that allows you to avoid having to go to the UI." -- better yet, git-extras (https://github.com/tj/git-extras https://github.com/tj/git-extras) provides CLI utils that work across github, gitlab, and bitbucket.