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

Git email flow vs. GitHub flow

blog.brixit.nl

Post reply on HN
Print view View original

141–150 of 177 posts

Re: Git email flow vs. GitHub flow

#141

Post by u801e »

WorldMaker wrote: post #118
ryukafalz wrote: post #67

Earlier quoted context omitted.

> Rapid changes to a PR is bad etiquette. Submit a PR for review, await comments, when received, prepare fixes and submit a new iteration. I think this depends a lot on context. GitHub now lets you open "draft" PRs, which are explicitly unmergeable until you mark them as ready. If I'm unsure of the approach I'm taking, it's helpful to be able to show my team what I have and ask for feedback before I've done the work…

Even before Draft PRs existed, I would often encourage especially junior devs to open PRs early and just include a note (in the description or the first commit) with a "Work in Progress" or "Not Ready to Merge" type comment and then either delete that (if in the description) or add a new comment with "Ready to Merge" or similar when ready. It's great to see GitHub add this as a real tool now, but there's always been…

> evolve them rapidly with discussion

That, in my experience makes it harder to review the change. To me, it's easier to do something like that while pair programming. Code review should be done once a final approach has been taken and only minor changes or factors that the implementation may not have taken into account should be addressed.

Re: Git email flow vs. GitHub flow

#142

Post by u801e »

jillesvangurp wrote: post #48
eeZah7Ux wrote: post #47

Earlier quoted context omitted.

The email workflow is objectively, measurably simpler and it works really well for kernel development. Look at the examples on sourcehut. Yes, it takes a moment to get used to something different, but that's a human problem.

It works well for people used to command line interfaces to email, mailing lists, and using cli tools exclusively. Old people in other words. No shame in that; I am one. But I'm well aware that I'm a minority. I mostly work with twenty somethings these days. Keeps me mentally younger than I have any right to be. Also forces me to keep updating my skill sets. In any case, I tick only one of those boxes as I use a lot…

> It works well for people used to command line interfaces to email, mailing lists, and using cli tools exclusively.

But don't most people use the CLI to run or edit their source code in some fashion?

Re: Git email flow vs. GitHub flow

#143

Post by u801e »

mugsie wrote: post #119
brandmeyer wrote: post #111

Earlier quoted context omitted.

The other big downside is that enforcing the unit of review to be a single commit instead of a branch tends to encourage over-large commits. Rebasing a series of related commits for gerrit is a major pain.

yeah - that is a pain in the beginning. Personally (this is completely anecdotal, and not backed by any serious data), I have found it drives people to do multiple small commits, as they rebase a lot easier. using something like git review means that the entire chain is rebased by default when you summit a new patch on top, and I have the `git commit --am -a --no-edit && git fetch && git rebase` in muscle memory at t…

How does Gerrit handle a group of commits in a branch? That it, if a feature takes several commits to implement and some of them depend on changes made in earlier commits in the branch, how do you ensure that the earlier commit is approved and applied to the main branch before the later commit?

Re: Git email flow vs. GitHub flow

#144

Post by u801e »

WorldMaker wrote: post #123
fishywang wrote: post #28

Earlier quoted context omitted.

(squash-n-merge isn't new on github, unless you are not talking about the same thing I'm thinking about) Yes squash-n-merge is often needed in github's PR workflow because no one need those un-bisect-able fixup commits in the final merged master/main branch, and also they make the diff between different states of the PR more readable, but it comes with its own problems. Main problem is commit message. As the contribu…

> un-bisect-able fixup commits in the final merged master/main branch If you require PRs to create merge commits you get the nice world where git bisect --first-parent bisects at the PR level, you don't have to worry about the individual commits inside the PR/below the PR level when bisecting, but you still have that commit history "as-is" for deep archeological dives when you need it. (And you can use --first-parent…

And those commits rarely provide useful information because they're of the variety where people fix syntax errors, add missing files, remove changes they didn't mean to commit, etc.

Re: Git email flow vs. GitHub flow

#145

Post by u801e »

WorldMaker wrote: post #125
pabs3 wrote: post #24

Earlier quoted context omitted.

Do you at least agree that merge commits for single-commit PRs aren't "appropriate"?

Merge commits for single-commit PRs helpfully record which PR # was merged if you need to review/audit the PR sometime later, if nothing else.

The original commit could be amended to include that information.

Re: Git email flow vs. GitHub flow

#146

Post by u801e »

WorldMaker wrote: post #121
ketozhang wrote: post #54

Earlier quoted context omitted.

Article did not mean force push to main branch, they mean force push to working branch when your working branch is behind main and requires a rebase. This is often avoided by doing a merge with main branch instead of a rebase.

Yes, most of the issues this article has with PR branches and needing to force push them stems from the self-imposed "requirement" that they don't like merge commits and don't allow them. Obviously that will make working with PRs much harder than the merge-based workflows that PRs were originally built for and still tend to be best optimized for.

The merge button merges the feature branch into the base branch. The merge commit provides information regarding what commits are in the branch (commits from the first to second parent). Merging the base branch into the feature branch introduces a merge commit that just shows changes to the base branch and conflicts that were addressed.

That information could just as well not be there if you created the feature branch from the main branch after the latter was updated. The merge commit doesn't really provide any useful information, which is why many consider it noise that shouldn't be in the commit history.

Re: Git email flow vs. GitHub flow

#147

Post by jillesvangurp »

ddevault wrote: post #76
jillesvangurp wrote: post #48

Earlier quoted context omitted.

It works well for people used to command line interfaces to email, mailing lists, and using cli tools exclusively. Old people in other words. No shame in that; I am one. But I'm well aware that I'm a minority. I mostly work with twenty somethings these days. Keeps me mentally younger than I have any right to be. Also forces me to keep updating my skill sets. In any case, I tick only one of those boxes as I use a lot…

This is a really nasty argument. "Old people" are (1) not the only people who understand mailing lists, (2) not the only people who like mailing lists, and (3) not "set in their ways", so to speak, or failing to "updating their skillset". There are plenty of "twenty-somethings" which use the email workflow. What a gross, ageist comment. >The nice innovation of the pull request by Github achieves a similar flow but wi…

If by plenty you mean a vanishingly small minority of twenty somethings, then yes you are completely right. They exist. Just not in very large numbers.

I'm merely making the observation that it's mostly older generations (like yourself?) that are 1) used to/familiar with this way of working 2) actually prefer doing so. There's nothing nasty intended here. I think you are taking this way too personal.

Re: Git email flow vs. GitHub flow

#148

Post by rakoo »

WorldMaker wrote: post #139
rakoo wrote: post #135

Earlier quoted context omitted.

XMPP Core is a replacement for SMTP. XMPP pubsub is much more than just pubsub, take a look at https://xmpp.org/extensions/xep-0060.html . There is everything about querying and forwarding, in this XEP and in https://xmpp.org/extensions/xep-0313.html . There is precedent for posting content and replying inside XMPP's pubsub as documented in https://xmpp.org/extensions/xep-0277.html ; the same can be used for general…

Fair points. I wasn't aware of any of these tools, but then like the majority of the world I haven't actively used XMPP in years (which is obviously among its largest cons today).

My intent wasn't to diminish your initial comment, just that a protocol is a technical answer to a problem that is more probably a societal one. It takes time and effort to commit to another communication protocol, especially when it's not the core of what you're doing as a project. Maybe what is needed is not just a protocol but proper tools to make it easy to use (and the bar with the simplicity of email is very high)

Re: Git email flow vs. GitHub flow

#149

Post by mugsie »

u801e wrote: post #143
mugsie wrote: post #119

Earlier quoted context omitted.

yeah - that is a pain in the beginning. Personally (this is completely anecdotal, and not backed by any serious data), I have found it drives people to do multiple small commits, as they rebase a lot easier. using something like git review means that the entire chain is rebased by default when you summit a new patch on top, and I have the `git commit --am -a --no-edit && git fetch && git rebase` in muscle memory at t…

How does Gerrit handle a group of commits in a branch? That it, if a feature takes several commits to implement and some of them depend on changes made in earlier commits in the branch, how do you ensure that the earlier commit is approved and applied to the main branch before the later commit?

it groups the branch into a chain of commits, and has dependancies between them, so you can approve a commit on top of the chain, but it will not merge until the ones it is based off merge.

Re: Git email flow vs. GitHub flow

#150

Post by ddevault »

jillesvangurp wrote: post #147
ddevault wrote: post #76

Earlier quoted context omitted.

This is a really nasty argument. "Old people" are (1) not the only people who understand mailing lists, (2) not the only people who like mailing lists, and (3) not "set in their ways", so to speak, or failing to "updating their skillset". There are plenty of "twenty-somethings" which use the email workflow. What a gross, ageist comment. >The nice innovation of the pull request by Github achieves a similar flow but wi…

If by plenty you mean a vanishingly small minority of twenty somethings, then yes you are completely right. They exist. Just not in very large numbers. I'm merely making the observation that it's mostly older generations (like yourself?) that are 1) used to/familiar with this way of working 2) actually prefer doing so. There's nothing nasty intended here. I think you are taking this way too personal.

I'm 27.
Post reply on HN