Live data from Hacker News

Git email flow vs. GitHub flow

blog.brixit.nl

41–50 of 177 posts

Re: Git email flow vs. GitHub flow

#41
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.

If I've correctly understood what you mean, I've wanted this for some time now. A way to preserve history while adding a single, linear integration of changes.

Re: Git email flow vs. GitHub flow

#42
post #18

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…

Gitlab has a great graph view

Re: Git email flow vs. GitHub flow

#43
I don't think it is a good idea to allow individuals the ability to force push changes to a branch where said force pushing allows them to impersonate others. If someone with said capabilities ever has their account compromised much less if said individual abuses their powers, you can end up with a scenario where all the provenance guarantees of your repo are gone.

For sensitive projects, ideally no code can be merged in unless it is reviewed by somebody else. Even if no malicious code is added, the extra layer of review adds at least some degree of accountability.

As for the issues the author mentions, Azure DevOps mostly solves these by having squash commits which can be set to autocomplete once fully approved via reviewers and CI. You can do merging manually in ADO, but most of the time I (the author of the PR) just rebase or merge manually before completing the PR or setting auto complete.

There is no VCS that I know of which handles many people modifying the same files simultaneously in a nice way. If you allow for more clever auto merging, you increase the likelihood your merge algorithm produces nonsense. The author should probably be doing this merging since they are the expert on their changes. I think the only real alternative would be if a VCS allowed for a custom merge algorithm (which could do different strategies for different files). A package.json file can't really be merged without some understanding of what a package.json file is or at the very least what a JSON file is.

Re: Git email flow vs. GitHub flow

#44
post #18

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…

The GitHub linear view that shows no graph is a real problem on my team, because at least one team member has no idea when they are creating a complex, unbisectable graph with their merge commits and no-message submodule updates.

To them the timeline is just a linear sequence of what everyone has been working on recently, mixed together. They do understand feature branches, but then they randomly merge their branches in progress and the result is still a mess somehow.

To me, seeing the `git log --graph`, it's a difficult to understand mess with redundant micro-branches and micro-merges. Randomly unrelated file changes and even file deletions also occur - `git commit` might as well mean "copy my working directory into the repo". As a result, the main branch quality varies and cannot be trusted from one day to the next.

The difference between us is I actually look at the repo history, I look at my commits before I commit them. They appear to commit things without even knowing what's going in, and don't look afterwards, as it's a surprise to them when I complain about things like a file deletion.

GitHub's commit history view is part of the problem, because its presented as if it's the main, primary way to look at the history. It's not the problem, but it makes things worse. Better visualisation tools would help, but for now everyone has their own "pet way" of using Git, I lack the social capital to convince anyone to do better, and the gravity of GitHub as "the way" makes it difficult to get anyone to care about any alternative way of viewing the repo. "It's what everyone uses".

GitHub issues similarly suck as a project management tool; guess what we're using.

Re: Git email flow vs. GitHub flow

#45
post #18

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…

> I prefer to work with branches rather than a bunch of loose patch files

The two are not mutually exclusive. You can have branches locally with the changes you're interested in and create patches from master to the tip of your branch. Same as a maintainer: you can apply patches in a different branch, check everything is alright and then merge it

Patches only live in the mailing list and are not supposed to be manually handled on your machine

Re: Git email flow vs. GitHub flow

#46
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.

I imagine it’s convenient to them but being difficult for everyone else is a feature. They don’t want people sending in random garbage code so the barrier to entry is kept high.

Re: Git email flow vs. GitHub flow

#47

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…

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.

Re: Git email flow vs. GitHub flow

#48

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…

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 of cli tools (including git of course), aggressively unsubscribe anything that looks like a mailing list (never had the patience for the low signal to noise ratio and horrible UX of having to mentally parse deeply nested threads). NNTP was always superior to that and the last time I worked with that is 15 years ago.

I have not used a cli email client since the mid nineties. I considered outlook express to be an upgrade back then. And that wasn't all that great if you think about it. I also used Thunderbird for a while until dropping the notion of having offline email archives on my laptop/computer entirely. These days I use gmail, slack, and a lot of other chat tools. All cloud based stuff. Mostly work related emails are very limited and restricted to interacting with non technical people and alerts/notifications. It is not part of any technical process I've used in the past decade.

I actually used git apply patch back in the day when I was transitioning from subversion to git and was stuck in a team insisting on subversion. Pretty cool way to move commits around and it allowed me to work around some limitations with git-svn (no rebases in svn); but not for everyone.

The nice innovation of the pull request by Github achieves a similar flow but with a pretty UI, easy to use tools for commenting, line by line review, search, issue tracker integration, and a bunch of other things that IMHO stopped being optional on most projects. I kind of like the traceability of PR #4 closes issue #13 and successfully cleared CI & received a positive review so it is safe to merge.

Kernel development has historically catered to the needs of the core committers, most of which have been working on this project for decades and one of which happens to be the inventor of Git. And of course anything kernel related tends to be very cli centric to begin with. And finally they do process a very large number of patches. So their use is very valid of course and I guess any tool changes are very disruptive there given the large amount of stakeholders. The statistics on that project are in any case mindblowing. You can get a good picture of that via Githubs insights on Linus Torvalds fork of linux. I don't think he uses pull requests though. Is there an issue tracker for linux even?

Re: Git email flow vs. GitHub flow

#49

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…

> it definitely has not been as straightforward as the pull-request workflow.

I agree - there's a bit of a setup phase, stemming a from email having degraded into "that thing you see on gmail.com". https://git-send-email.io/ is nice for validating the setup when in doubt.

However, once the flow runs, I think it's more straight forward than a pull-request workflow.

> I do also like being able to update an existing PR as I'm making rapid changes though

Rapid changes to a PR is bad etiquette. Submit a PR for review, await comments, when received, prepare fixes and submit a new iteration.

Submitting changes after opening a PR that isn't to just to fix CI results is just noise, and suggests that you erroneously opened a PR for review before you were ready for review. Submitting changes little by little likewise suggests that you're still working on an open PR, making noise and and making it hard to see when I should resume my review.

Don't push anything to a PR you don't want me to review and merge. Hold off until then.

> Uh, you press a button.

Yeah, it's easy, but that button has lead to so many bad git habits. Including, say, not caring about their git history and expecting the reviewer to squash everything into ugly commits.

Re: Git email flow vs. GitHub flow

#50
I still don't understand why, for projects and similar topics-based discussion, we don't use NNTP instead of Email. Email is good for addressing specific people only, and you're supposed to have been part of the conversation since the beginning so it does apply to personal correspondence but it scales horribly bad for groups of people:

- there is no included history. You need to manually download hand-crafted archives from a bespoke endpoint but then you need to import it all. If you want to quickly read some old message there needs to be a relay to a public inbox type of thing which is a hack

- mailing lists software exist but they are another hack. There is no standard for subscribing or unsubscribing

- projects often have multiple lists anyway so they need to install them all

All of these issues are solved with a network of NNTP servers, and even more: automatic backup of posts because that's how NNTP works, messages are shared accross the network so every message has a specific URI (https://tools.ietf.org/html/rfc5538) and can be addressed directly and retrieved on-the-fly if needed

Post reply on HN