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

1–10 of 177 posts

Re: Git email flow vs. GitHub flow

#3

Post by twobitshifter »

This is the first I’ve heard of sourcehut. I agree that it’s a better method. Sticking closer to text and staying away from vendor lock-in is the way to go from my perspective. I’m not anal about my git history, so I can use the GitHub or Gitlqv workflow, without problems, but this would be an improvement.

Re: Git email flow vs. GitHub flow

#4

Post by alberth »

twobitshifter wrote: post #3

This is the first I’ve heard of sourcehut. I agree that it’s a better method. Sticking closer to text and staying away from vendor lock-in is the way to go from my perspective. I’m not anal about my git history, so I can use the GitHub or Gitlqv workflow, without problems, but this would be an improvement.

Drew, who created Sourcehut, is very active on HN

https://news.ycombinator.com/user?id=ddevault

Re: Git email flow vs. GitHub flow

#5

Post by properdine »

Understand where author is coming from - but doesn't squash-n-merge (newish github feature) solve the issue of needing to rebase and the issue of having too many merge commits?

Squash-n-merge has nice property of removing unnecessary local information that probably doesn't matter at a meta level (commits are nice when reviewing PR, doesn't matter much later)

Re: Git email flow vs. GitHub flow

#6

Post by javitury »

Reading this article has changed the impression I had about git-mail-flow. Naturally, more questions came to my mind.

Is a git-mail-flow compatible with continuous integration? Yes, it seems to be

https://sourcehut.org/blog/2020-07-14-setting-up-ci-for-mail...

Is it possible to construct ergonomic workflows around a git-mail-flow? I suspect you could do it with notmuch and alot, although I wonder which tools do sourcehut users prefer.

Re: Git email flow vs. GitHub flow

#7

Post by pabs3 »

properdine wrote: post #5

Understand where author is coming from - but doesn't squash-n-merge (newish github feature) solve the issue of needing to rebase and the issue of having too many merge commits? Squash-n-merge has nice property of removing unnecessary local information that probably doesn't matter at a meta level (commits are nice when reviewing PR, doesn't matter much later)

Squashing commits into one mega-commit isn't great for future investigations of the commit history (code review, bisects etc). It is much better to create separate logical commits, rebase them and pull in the result, either as a branch fast-forward merge, or with a merge commit where appropriate.

Re: Git email flow vs. GitHub flow

#8

Post by properdine »

pabs3 wrote: post #7
properdine wrote: post #5

Understand where author is coming from - but doesn't squash-n-merge (newish github feature) solve the issue of needing to rebase and the issue of having too many merge commits? Squash-n-merge has nice property of removing unnecessary local information that probably doesn't matter at a meta level (commits are nice when reviewing PR, doesn't matter much later)

Squashing commits into one mega-commit isn't great for future investigations of the commit history (code review, bisects etc). It is much better to create separate logical commits, rebase them and pull in the result, either as a branch fast-forward merge, or with a merge commit where appropriate.

a year from now, are you actually going to want to test each individual change in a pull request, or are you going to want to test it as an entire unit?

I agree that code review you want smaller units but my experience has been that 1-2 years later, you no longer care about the individual units and instead you want the entire patch/PR all together.

Re: Git email flow vs. GitHub flow

#9

Post by IgorPartola »

javitury wrote: post #6

Reading this article has changed the impression I had about git-mail-flow. Naturally, more questions came to my mind. Is a git-mail-flow compatible with continuous integration? Yes, it seems to be https://sourcehut.org/blog/2020-07-14-setting-up-ci-for-mail... Is it possible to construct ergonomic workflows around a git-mail-flow? I suspect you could do it with notmuch and alot, although I wonder which tools do sourc…

The Linux kernel uses email. I can’t imagine that crowd does things the inconvenient way.

Re: Git email flow vs. GitHub flow

#10

Post by dboreham »

properdine wrote: post #8
pabs3 wrote: post #7

Earlier quoted context omitted.

Squashing commits into one mega-commit isn't great for future investigations of the commit history (code review, bisects etc). It is much better to create separate logical commits, rebase them and pull in the result, either as a branch fast-forward merge, or with a merge commit where appropriate.

a year from now, are you actually going to want to test each individual change in a pull request, or are you going to want to test it as an entire unit? I agree that code review you want smaller units but my experience has been that 1-2 years later, you no longer care about the individual units and instead you want the entire patch/PR all together.

I think it's more about: in a year from now will you understand the purpose of a change to some code you're debugging? If the commit says "merged PR 2234", answer is probably not.
Post reply on HN