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

121–130 of 177 posts

Re: Git email flow vs. GitHub flow

#121

Post by WorldMaker »

ketozhang wrote: post #54
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.

Yes, most of the issues this article has with PR branches and needing to force push them stems from the self-imposed "requirement" that they don't like merge commits and don't allow them. Obviously that will make working with PRs much harder than the merge-based workflows that PRs were originally built for and still tend to be best optimized for.

Re: Git email flow vs. GitHub flow

#122

Post by mixedCase »

ClumsyPilot wrote: post #110
mixedCase wrote: post #102

Earlier quoted context omitted.

So, for Windows compatibility layers.

So you havent read 90% of the article about languages with mutiple alphabets or efficient search, but you are willing to argue anyway. Thanks for proving my point.

I read it, even though you could be succintly making your points here instead of linking generic articles, and that's why I surfaced the only thing I considered valid.

The usecase you bring up, including the multiple scripts issue, is search. And it's not and should not be a filesystem concern which optimizes for a different kind of access from which you can build search on top of.

Re: Git email flow vs. GitHub flow

#123

Post by WorldMaker »

fishywang wrote: post #28
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 contribu…

> un-bisect-able fixup commits in the final merged master/main branch

If you require PRs to create merge commits you get the nice world where git bisect --first-parent bisects at the PR level, you don't have to worry about the individual commits inside the PR/below the PR level when bisecting, but you still have that commit history "as-is" for deep archeological dives when you need it.

(And you can use --first-parent to cleanup git log and git praise too.)

Re: Git email flow vs. GitHub flow

#124

Post by WorldMaker »

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.

Yup, and you can use --first-parent to git bisect, git log, git praise to interact at the "macro-level" of those merge commits by default, and dive in to the fuller graph only as necessary.

Re: Git email flow vs. GitHub flow

#125

Post by WorldMaker »

pabs3 wrote: post #24
rectang wrote: post #22

Earlier quoted context omitted.

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"?

Merge commits for single-commit PRs helpfully record which PR # was merged if you need to review/audit the PR sometime later, if nothing else.

Re: Git email flow vs. GitHub flow

#126

Post by WorldMaker »

da39a3ee wrote: post #101

If a patch is in an email then how do you know which parent commit it should be applied to? A patch is not a thing in its own right in isolation; it should come with a specified parent thus identifying a unique code context in which it is correct. Just because it applies cleanly on a branch does not mean it is correct there.

This is one reason I far more trusted email workflows around darcs than I do with git. In darcs patches were first class objects (including a ton of context information), but in git that sort of information has to travel in manually and in parallel in the email thread.

Re: Git email flow vs. GitHub flow

#127

Post by masklinn »

rectang wrote: post #113
masklinn wrote: post #30

Earlier quoted context omitted.

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

A pull is just a fetch followed by a merge. So to solve this problem, just fetch instead of pull! Then do `git merge --ff-only` and if it doesn't work, do the rebase or whatever else to resolve the conflict. I did this long before I set `merge.ff=no`. I hate it when pull creates crappy graphs — it's something I try to help all my colleagues to avoid. I often wish that `git pull` didn't exist.

> A pull is just a fetch followed by a merge. So to solve this problem, just fetch instead of pull!

Of course, that’s what I do. But “git pull” is still a danger, and configuring merge.ff=only protects against that danger.

Re: Git email flow vs. GitHub flow

#128

Post by rakoo »

u801e wrote: post #97
rakoo wrote: post #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 archive…

I've brought up the same point in a number of threads that have brought up mailing lists over the years. In the specific case of mailing lists like the ones used for Linux kernel and git development, I believe many participants host their own SMTP instances and use them to send and receive messages and have had those set ups for a long time. If they were to switch to NNTP, they would either have to: 1. Create a new g…

public-inbox seems to be the best of both worlds indeed. Interestingly it fits your option 1: posting is open and the admin is in charge of handling spam.

But public-inbox goes way further with other means of pulling, and the easy and trusted replication gives it the same status as the code: the repo is the source of truth, not the email endpoint. I could see projects using that and, say, gitolite as the two main bricks for running a project. Now all we need is a simple CI/CD system that is designed to run on its own rather than in a specific ecosystem

Re: Git email flow vs. GitHub flow

#129

Post by ClumsyPilot »

yakubin wrote: post #112
ClumsyPilot wrote: post #107

Earlier quoted context omitted.

Thank you gor being exhibit A If you bothered reading the link, all of these questions have been addressed long ago by folks are are more knowledgeable than either one of us. The rules are spesific to each language, and are especially neccesary for languages thay have several alphabets. Without this functionality, efficient search is impossible. This silly, forcefull and uninformed critisism is exactly the kind of be…

I have bothered to read the link. The point of those questions wasn't to see if there are answers to them. The point of those questions was to show that all answers to them are flawed. Yes, the link provides one set of answers. (Except for the backwards-compatibility and changing language question.) But it doesn't solve the problem. When you want case-insensitive search, it's the search tool's job to provide it. E.g.…

"The point of those questions was to show that all answers to them are flawed."

Whats flawed? Where is it flawed? You provide no arguments at all!

"When you want case-insensitive search, it's the search tool's job to provide it."

I dont know if you didnt read it, or missed it, but the article clearlerly explains that the tool above the FS cannot do such a search performantly, it has to happen at the FS layer

"You don't change the file system to normalize characters inside files."

Where does this certainty come from? Why do you offer no technical argument to support your position? Is this by Pope's decree?

Can you demonstrate a tool that can search efficiently in different alphabets, or when the same character is presentes by different unicode codepoints?

Reading replies here convinces me even more that you just picked 'something something windows' and react like a bull does to a red rag.

Not a single good technical counterargument has beed presented

Re: Git email flow vs. GitHub flow

#130

Post by ClumsyPilot »

mixedCase wrote: post #122
ClumsyPilot wrote: post #110

Earlier quoted context omitted.

So you havent read 90% of the article about languages with mutiple alphabets or efficient search, but you are willing to argue anyway. Thanks for proving my point.

I read it, even though you could be succintly making your points here instead of linking generic articles, and that's why I surfaced the only thing I considered valid. The usecase you bring up, including the multiple scripts issue, is search. And it's not and should not be a filesystem concern which optimizes for a different kind of access from which you can build search on top of.

The article is not generic, it is spesific to the issue being discussed, and it explains the issue better than I can.

"And it's not and should not be a filesystem concern which optimizes for a different kind of access"

Why not? Is that by Pope's decree, or is there an actual reason for that?

The filesystem already has like 3 different APIs, with and without caches, sync and async, so clearly they do optimise for different kinds of access.

Can you demonstrate a tool that can search efficiently in different alphabets, or when the same character is presentes by different unicode codepoints?

Post reply on HN