Thank you!
I’ve heard that Linus Torvalds disliked GitHub pull requests in part because they tried to reinvent the wheel instead of using Git’s native system. I wasn’t clear on what that native system was until reading this article.
Git email flow vs. GitHub flow
31–40 of 177 posts
Re: Git email flow vs. GitHub flow
#32Earlier quoted context omitted.
Inconvenient to who? There a many things in Linux that anyone who doesn’t use Linux full time finds majorly inconvenient, a lot of the UX around Linux is only intuitive to the 45 year old graybeard. To us 30 year old win DevOps guys Linux isn’t actually that “convenient” out of the box.
They were talking about development of the Linux kernel, not using the OS. But I also take issue with your “graybeard” comment. Unix has won out for a reason, I and many other who aren’t old hats prefer the flow of development and deployment on Linux/Unix to that of Windows.
Especially in the frontend world it all seems to be unix command line.
Re: Git email flow vs. GitHub flow
#33Understand 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)
Sometimes (often!) you want clean history in the upstream but also patches separated by bugs they fix, features they add -- issue/ticket numbers, whatever. And you may want regression tests to come before bug fixes, that way you can see the regression test failing, then the test passing after applying the bug fix. Different upstreams are likely to have different rules.
So squash-and-merge is a bad one-size-fits-all. Rebase is a much much better approach: you keep the history as submitted and you lose the useless merge commit. There's no "unnecessary local information" if the submitter did the work of cleaning up their history before submitting. That means doing interactive rebases locally to squash/fixup/edit(and-possibly-split)/reword/drop/reorder their commits -- this is something every developer should know how to do.
Re: Git email flow vs. GitHub flow
#34Has anyone ever used fossil?
https://fossil-scm.org/
Re: Git email flow vs. GitHub flow
#35Understand 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)
(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…
You can work around all of this as a contributor by squashing on your own end before the final merge.
Re: Git email flow vs. GitHub flow
#36Earlier quoted context omitted.
Inconvenient to who? There a many things in Linux that anyone who doesn’t use Linux full time finds majorly inconvenient, a lot of the UX around Linux is only intuitive to the 45 year old graybeard. To us 30 year old win DevOps guys Linux isn’t actually that “convenient” out of the box.
They were talking about development of the Linux kernel, not using the OS. But I also take issue with your “graybeard” comment. Unix has won out for a reason, I and many other who aren’t old hats prefer the flow of development and deployment on Linux/Unix to that of Windows.
> Unix has won out
Nop, it doesn’t. Linux, which is a Unix clone, has won on some category of computers (notably servers) but most unices derivativing from the original one have a marginal market share.
> for a reason
Price mostly, and access to sources.
Re: Git email flow vs. GitHub flow
#37Reading 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.
I can't imagine that crowd doing it anything but their preferred way.
Remember when a Debian maintainer quit due to the obsoleteness of the toolchain that the other maintainers flat out refused improve because "it worked" ( my google-fu is failing me, if someone finds it please post it)? I imagine things to be the same with the kernel ( not saying the toolchain is obsolete, just that if it were, they won't just change and jump to the latest X).
Re: Git email flow vs. GitHub flow
#38I suspect that people who are used to working in small, integrated teams are more used to using the github flow (aka, a web tool to do code reviews which also integrates git commands). People who are more used to a hub and spoke model - aka, a maintainer receiving tonnes of patches from many different people - would prefer the git email flow (it requires less work from them - patches that don't merge is pushed back t…
For small, integrated teams, github flow may be suboptimal. Frequent merging to master, aka trunk-based development, aka Continuous Integration is the way to go for me.
Re: Git email flow vs. GitHub flow
#39Sourcehut.org is as close to using “stock” git as you can get. It’s also email based flow. See the following write up this 2018 write up on email vs GitHub flow https://drewdevault.com/2018/07/02/Email-driven-git.html
It's a while I've switched to sourcehut and learned the email workflow for the first time. It was easier than I thought, and I am very pleased with the outcome. Perhaps leaving megacorp mail clients behind had helped me to embrace this workflow faster.
Re: Git email flow vs. GitHub flow
#40Sourcehut.org is as close to using “stock” git as you can get. It’s also email based flow. See the following write up this 2018 write up on email vs GitHub flow https://drewdevault.com/2018/07/02/Email-driven-git.html
And it's free; and the web interface has no JS, if you're into that sort of thing.
I assume you mean free software? Since sourcehut is intentionally a paid service for hosting content, albeit free during beta and for contributors.