Git email flow vs. GitHub flow • Hacker News Board

Re: Git email flow vs. GitHub flow

#11

Post by ddevault » Tue, Mar 30, 2021, 2:06 AM UTC

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…

I use an email client I wrote for this purpose:

https://aerc-mail.org/

Greg-KH has also written about his mutt workflow:

http://www.kroah.com/log/blog/2019/08/14/patch-workflow-with...

Though his volume and needs are probably different from most users.

Re: Git email flow vs. GitHub flow

#12

Post by pabs3 » Tue, Mar 30, 2021, 2:08 AM UTC

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 definitely will want to do that, especially when bisecting a random bug that was introduced with one of the changes in that PR. The smaller the unit of change the better, as long as they are logically separate changes.

Re: Git email flow vs. GitHub flow

#13

Post by rectang » Tue, Mar 30, 2021, 2:20 AM UTC

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.

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 log --oneline --graph` to see a clean representation of the actual history.

Re: Git email flow vs. GitHub flow

#14

Post by chii » Tue, Mar 30, 2021, 2:27 AM UTC

I 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 to the contributor).

Re: Git email flow vs. GitHub flow

#15

Post by ryukafalz » Tue, Mar 30, 2021, 2:52 AM UTC

I like the decentralization aspect, but every time I've had to send patches by email... it definitely has not been as straightforward as the pull-request workflow. I suppose part of that has to do with the project I have experience with using Debbugs (which requires that subsequent patches in a patchset be sent to a newly created address rather than all of them being sent to the same email address). I might like it better if I were contributing to something using lists.sr.ht and could just set the default list address for the project and not worry about it.

I do also like being able to update an existing PR as I'm making rapid changes though, and just pushing up to whatever branch my PR references is also really nice. (It's, what, 5 keystrokes to push my latest changes to my remote for that branch? And that's assuming I don't already have the git status buffer open.)

Applying a PR is also straightforward, which matters especially for newer users. Uh, you press a button.

I'm all for decentralization, but this is the UX you're up against.

Re: Git email flow vs. GitHub flow

#16

Post by pgaddict » Tue, Mar 30, 2021, 3:03 AM UTC

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'm pretty sure you want reasonable meaningful commits. On tiny projects it may not matter, but on larger projects it's definitely a huge benefit, because chances are you'll have to investigate a bug in that code, re-learn why it was done this way, etc. And maybe bisect the git history to find which exact commit caused the issue.

Which is why larger changes are often split into smaller patches that may be applied and tested incrementally. If you just merge the whole pull request as one huge patch / in merge commit, you just lost most of that.

Re: Git email flow vs. GitHub flow

#17

Post by earthboundkid » Tue, Mar 30, 2021, 3:22 AM UTC

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.

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

Re: Git email flow vs. GitHub flow

#18

Post by rectang » Tue, Mar 30, 2021, 3:36 AM UTC

ryukafalz wrote: post #15

I like the decentralization aspect, but every time I've had to send patches by email... it definitely has not been as straightforward as the pull-request workflow. I suppose part of that has to do with the project I have experience with using Debbugs (which requires that subsequent patches in a patchset be sent to a newly created address rather than all of them being sent to the same email address). I might like it b…

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 branch lines of development. Give me `git log --graph`!

Re: Git email flow vs. GitHub flow

#19

Post by pabs3 » Tue, Mar 30, 2021, 3:45 AM UTC

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…

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.

Re: Git email flow vs. GitHub flow

#20

Post by pabs3 » Tue, Mar 30, 2021, 3:48 AM UTC

rectang wrote: post #18

ryukafalz wrote: post #15

I like the decentralization aspect, but every time I've had to send patches by email... it definitely has not been as straightforward as the pull-request workflow. I suppose part of that has to do with the project I have experience with using Debbugs (which requires that subsequent patches in a patchset be sent to a newly created address rather than all of them being sent to the same email address). I might like it b…

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.