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

21–30 of 177 posts

Re: Git email flow vs. GitHub flow

#21

Post by rectang »

pabs3 wrote: post #20
rectang wrote: post #18

Earlier quoted context omitted.

Yeah, I've got strong git skillz and could handle the email workflow, but I prefer to work with branches rather than a bunch of loose patch files. There are a couple things I strongly dislike about Github though. Number one: the default commit history display with commits force-linearized by date, which is just messed up and wrong when actual Git history can only be properly modeled with a topological view revealing…

There are lots of graphical history viewers, I use gitk mostly and git-big-picture to get a graphical overview graph without individual commits. The gitg GUI from GNOME is fairly good too, and of course there are better tools for proprietary operating systems.

For local development, I'm actually content with what I get from the Git command line interface: I use a slightly customized variant of `git log --oneline --graph`.

The problem is that I am often browsing the history of repositories hosted on Github via the Github web interface, along with other interactions such as searching through issues and PR history. Cloning a repo to my local machine and firing up gitk is a pretty inconvenient interruption of the web browsing experience.

Re: Git email flow vs. GitHub flow

#22

Post by rectang »

pabs3 wrote: post #19
rectang wrote: post #13

Earlier quoted context omitted.

Nirvana is: • Setting `merge.ff=no` in git config to force merge commits by default. • Creating a series of logical commits on `my-feature-branch`. • Merging `my-feature-branch` into `main` with a bona fide merge commit. • Using `git branch -d my-feature-branch` (NOT capital `-D`) to delete the feature branch safely and without worry, since `-d` only deletes the branch if the commits are present on HEAD. • Using `git…

I would only use merge commits when it is appropriate, like a commit series porting usage of a dependency from an old version to a new one.

Well, there are different views of "appropriate". When you do team development and everything is done via feature branches, it's nice to have merge commits so that the integrity of the each feature development effort is preserved via a merged branch in the history. If everything is flattened, it's harder to see where the branches (standing in for development initiatives) begin and end.

You can't always get fast-forward merges anyway. Long-lived branches with merge conflicts are undesirable but unavoidable in the long run. At least some of the time, you're going to have merge commits even when your "appropriateness" test says there shouldn't be one.

Re: Git email flow vs. GitHub flow

#23

Post by vxNsr »

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

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.

Re: Git email flow vs. GitHub flow

#24

Post by pabs3 »

rectang wrote: post #22
pabs3 wrote: post #19

Earlier quoted context omitted.

I would only use merge commits when it is appropriate, like a commit series porting usage of a dependency from an old version to a new one.

Well, there are different views of "appropriate". When you do team development and everything is done via feature branches, it's nice to have merge commits so that the integrity of the each feature development effort is preserved via a merged branch in the history. If everything is flattened, it's harder to see where the branches (standing in for development initiatives) begin and end. You can't always get fast-forwa…

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

Re: Git email flow vs. GitHub flow

#25

Post by maliegrl »

Platforms like GitHub and GitLab should support a workflow consisting of series of patches instead of a specific commit on a particular branch. They could probably even show pull requests from email in their interface.

Re: Git email flow vs. GitHub flow

#26

Post by edgyquant »

vxNsr wrote: post #23
IgorPartola wrote: post #9

Earlier quoted context omitted.

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

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.

Re: Git email flow vs. GitHub flow

#27

Post by hashkb »

alberth wrote: post #2

Sourcehut.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.

Re: Git email flow vs. GitHub flow

#28

Post by fishywang »

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)

(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 contributor (the one sending out the PR for maintainer to review), you have no control on what the final commit message in the merged single commit is. The maintainer doing the merge decides that for you, and by default github generates that message by combining all the commit message titles (the first line of the commit messages) of all the commits in that branch, and that's almost never the good choice for the final commit message.

Another problem with that is the email in the final commit. When the maintainer use squash-n-merge, github uses your default email on file on your github account, regardless whichever email(s) you configured your git to use and associated with those individual commits inside the PR.

As a result, squash-n-merge is more suitable for contributors less familiar with open source contribution, for example people not yet realized the value of a good, concise commit message, and people don't have different email addresses for different projects. For advanced contributors, there's no wonder they would prefer force-push with rebase-merge when they are making contributions on github, because rebase-merge makes sure the exact state of their final commit is preserved, including commit message, email address associated with it, and gpg signature if they use that. But github's rebase-merge strategy has its own issues, as described by the author and more.

Re: Git email flow vs. GitHub flow

#29

Post by renewiltord »

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

When someone invents the git killer, it will have a feature called “subcommits” that will be blindingly obvious in hindsight.

You get this by forcing merge commits for every non-single-commit change.

Re: Git email flow vs. GitHub flow

#30

Post by masklinn »

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

Nirvana is: • Setting `merge.ff=no` in git config to force merge commits by default. • Creating a series of logical commits on `my-feature-branch`. • Merging `my-feature-branch` into `main` with a bona fide merge commit. • Using `git branch -d my-feature-branch` (NOT capital `-D`) to delete the feature branch safely and without worry, since `-d` only deletes the branch if the commits are present on HEAD. • Using `git…

> • Setting `merge.ff=no` in git config to force merge commits by default.

I'd rather `merge.ff = only` so git never creates a merge commit from under me. It's a big issue because of `git pull`, that thing should not exist.

Most git tools are wholly unable to deal with really merge-heavy graphs, too.

Post reply on HN