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

51–60 of 177 posts

Re: Git email flow vs. GitHub flow

#51

Post by halayli »

slaymaker1907 wrote: post #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 merge…

you are force pushing to your own branch. It's also frequently done when you rebase your branch.

Re: Git email flow vs. GitHub flow

#52

Post by 600frogs »

The author suggests that if I find email horrible to work with, it's my mail client that's at fault, but doesn't expand as to why this is or make any suggestions for what to use - can anyone help me out here? What am I missing from some amazing holy grail mail client that I don't get in gmail webapp or the default MacOS mail app?

Re: Git email flow vs. GitHub flow

#53

Post by lelanthran »

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.

> To us 30 year old win DevOps

There's your problem right there. If you expect unix models to follow the particular broken-by-design failures of Windows on the server then that's the problem.

Unix models have their own broken-by-design crap, and it is different to the one you know :-)

Re: Git email flow vs. GitHub flow

#54

Post by ketozhang »

slaymaker1907 wrote: post #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 merge…

Article did not mean force push to main branch, they mean force push to working branch when your working branch is behind main and requires a rebase.

This is often avoided by doing a merge with main branch instead of a rebase.

Re: Git email flow vs. GitHub flow

#55

Post by maeln »

> If your main complaint is that email is horrible to work with, the issue is most likely not email, it's probably your mail client.

This is definitely talking from someone who never had to write software that deal with emails. The reality with emails ? They are an horrible format. There is several RFC describing the "email" format, the usual reference is rfc2822, but technically, you can find other rfc that relate to it (ex, the MIME rfcs: RFC 20452, RFC 20463, RFC 20474, RFC 20485, RFC 2049, RFC 68388, RFC 4289, ...). There is a lot that left to be desired in those RFC in term of specifications. They tend to gloss over some part and also allow several format for retro-compatibility.

But then, even the part that are clear and well defined are not respected. I wrote software that dealt with emails for a company that receive several thousands emails on several mailbox everyday. The number of non-complying email that we received that broke our implementation was staggering. Nobody respect the date format, that is standard any more. Then we had some weird stuff, like fields that were mime-encoded even though the spec explicitly say it must not be, attachment metadata that were written completely wrong, headers that made no sense, ... And this was not from your small email provider, it was emails that were coming from a gmail mailbox, outlook, yahoo, ...

Oh and MIME is the best footgun in existence. It allows you to do anything and so of course, you receive anything, including mail-in-mail-in-attachement-in-mixed-content-in-multipart. And you better hope that the boundary are not bugged.

I wrote HTTP servers, IRC clients, BMP parser, and many more format. Nothing ever came close to the mess that is email. Anything is better than email, that is not the clients fault, it's the format fault. We just keep using it because of network effect. But you can bet that any other communication protocol / format sucks less than email.

Re: Git email flow vs. GitHub flow

#56

Post by urxvtcd »

renewiltord wrote: post #29
earthboundkid wrote: post #17

Earlier quoted context omitted.

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.

Not sure why you are being downvoted. You actually can use merge commits this way, by viewing the diff produced by

    git diff $merge_commit^...$merge_commit^2
when interested in whole change-set introduced by a branch or looking at individual commmits when interested in well, individual commits.

Re: Git email flow vs. GitHub flow

#57

Post by nethead »

sofixa wrote: post #37
IgorPartola wrote: post #9

Earlier quoted context omitted.

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 chang…

This one: https://michael.stapelberg.ch/posts/2019-03-10-debian-windin... ?

Re: Git email flow vs. GitHub flow

#58

Post by mugsie »

For me the happy medium is something like gerrit. It works on the one change, one patch, one commit strategy, which helps with the ability to rebase for fast moving code, makes it easier to view CI results for a patch, and is slightly more user friendly for comments / reviews.

It also allows for a group of people to be co-maintainers (e.g. 2 people need to approve a patch before it get merged), and when tied into a CI tool like zuul-ci can help projects be sure the CI tests are testing the actual merged state of the project.

The downsides are people need to learn how to rebase, use git commit --ammend, and for the easiest submission install something like git-review or repo to submit patches. (it is possible to use gerrit without them, but remembering the syntax of git push refs/for/ can be difficult.

Re: Git email flow vs. GitHub flow

#59

Post by Marazan »

maeln wrote: post #55

> If your main complaint is that email is horrible to work with, the issue is most likely not email, it's probably your mail client. This is definitely talking from someone who never had to write software that deal with emails. The reality with emails ? They are an horrible format. There is several RFC describing the "email" format, the usual reference is rfc2822, but technically, you can find other rfc that relate t…

Once, many years ago, I started writing a library for dealing with IMAP mailboxes.

My take way is I have no idea how on earth people have actual working IMAP implementations.

Re: Git email flow vs. GitHub flow

#60

Post by chii »

gocartStatue wrote: post #38
chii wrote: post #14

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

> trunk-based development, aka Continuous Integration

continuous integration isn't trunk-based development (where everyone merges into the same master branch)!

Post reply on HN