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

111–120 of 177 posts

Re: Git email flow vs. GitHub flow

#111

Post by brandmeyer »

mugsie wrote: post #58

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

The other big downside is that enforcing the unit of review to be a single commit instead of a branch tends to encourage over-large commits. Rebasing a series of related commits for gerrit is a major pain.

Re: Git email flow vs. GitHub flow

#112

Post by yakubin »

ClumsyPilot wrote: post #107
yakubin wrote: post #104

Earlier quoted context omitted.

Should that work different for different languages? Imagine the mess. Maybe the file names aren't even written in any human language. Should we use English rules for all languages? Why? What makes English so special that English characters would be normalized, but characters from the native language of the user won't? Wouldn't that trip people up? Case-insensitive file systems are mostly advocated for by those who on…

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. whenever you want to do a case-insensitive search inside a file, you pass "-i" to grep or click a checkbox in a GUI. You don't change the file system to normalize characters inside files.

From the link, it also seems like the main motivation for the change is compatibility with Windows software. In particular, it mentions that it isn't something that should be enabled globally in the file system. It really isn't a convenience for the user.

The article makes a good case for providing compatibility with Windows software. But not for much else.

Thank you gor being exhibit A

Re: Git email flow vs. GitHub flow

#113

Post by rectang »

masklinn wrote: post #30
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…

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

Re: Git email flow vs. GitHub flow

#114

Post by sreevisakh »

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.

I have wondered the same too for a long time. But I have never seen the branching commit mentioned. Instead, most of the contributor documentation just ask you to rebase your feature branch on the latest master (or whatever it is called now) and send in those patches.

I believe that patchset application is treated the same way as rebasing. It should be possible to apply patches to the master without conflicts as long as the two branches haven't diverged too much. In case the branches did diverge a lot, the contributor is expected to sort it out by the rebase mentioned above. Patch workflow forces you to think about diff introduced by each commit, instead of worrying only about conflicts between two branches when merging.

Ultimately, it requires care and discipline from contributor and maintainer that is not strictly necessary with fork-PR workflow. However, commit quality would improve a lot if the same discipline was followed everywhere.

Re: Git email flow vs. GitHub flow

#115

Post by earthboundkid »

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.

Sure, you can use git to do this, but the git killer will have it as an expected capability.

I also think that octopus merges are basically always a disaster because they can't be meaningfully reviewed and put your repo into an unknown state. Maybe there's some way to get the advantages of merge commits (preserve all history!) without the disadvantages (jumble all history!).

Re: Git email flow vs. GitHub flow

#116

Post by fishywang »

Ar-Curunir wrote: post #35
fishywang wrote: post #28

Earlier quoted context omitted.

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

You can work around all of this as a contributor by squashing on your own end before the final merge.

That comes with all the problems with force push and rebase, bar the history during code review one.

For example this still has a commit message issue, just on the maintainer's side: As the maintainer if you are going to use rebase to merge this PR, that means you need to accept whatever commit message the contributor wrote as-is. Are you happy with that? If not, you can't even leave inline comments on that, and it's usually pretty hard to communicate and give feedback on how you want the commit message to be.

Re: Git email flow vs. GitHub flow

#117

Post by WorldMaker »

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…

Given gmane's funding crises over the years, it feels hard to recommend relying on such a service long term. (Though I've certainly relied on it over the years for a number of different reasons.)

What we almost need is an NNTP 2.0 that makes it easier for smaller federated groups. (Maybe this is a good use for ActivityPub and/or Matrix?)

(Public-Inbox is new to me and at first skim seems to cover some interesting bases here. I'm not thrilled at the AGPL licensing though.)

Re: Git email flow vs. GitHub flow

#118

Post by WorldMaker »

ryukafalz wrote: post #67
arghwhat wrote: post #49

Earlier quoted context omitted.

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

> Rapid changes to a PR is bad etiquette. Submit a PR for review, await comments, when received, prepare fixes and submit a new iteration. I think this depends a lot on context. GitHub now lets you open "draft" PRs, which are explicitly unmergeable until you mark them as ready. If I'm unsure of the approach I'm taking, it's helpful to be able to show my team what I have and ask for feedback before I've done the work…

Even before Draft PRs existed, I would often encourage especially junior devs to open PRs early and just include a note (in the description or the first commit) with a "Work in Progress" or "Not Ready to Merge" type comment and then either delete that (if in the description) or add a new comment with "Ready to Merge" or similar when ready.

It's great to see GitHub add this as a real tool now, but there's always been lots of good reasons to open PRs early, evolve them rapidly with discussion, and merge them only once discussion converges. It can be a useful workflow for some types of teams.

Re: Git email flow vs. GitHub flow

#119

Post by mugsie »

brandmeyer wrote: post #111
mugsie wrote: post #58

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

The other big downside is that enforcing the unit of review to be a single commit instead of a branch tends to encourage over-large commits. Rebasing a series of related commits for gerrit is a major pain.

yeah - that is a pain in the beginning.

Personally (this is completely anecdotal, and not backed by any serious data), I have found it drives people to do multiple small commits, as they rebase a lot easier.

using something like git review means that the entire chain is rebased by default when you summit a new patch on top, and I have the `git commit --am -a --no-edit && git fetch && git rebase` in muscle memory at this point.

(the lack of ability to have PRs based off other open PRs is one of the biggest issues I have with the current github / pull request model, so I probably over compensate for that type of situation)

Re: Git email flow vs. GitHub flow

#120

Post by WorldMaker »

jlokier wrote: post #44
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…

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…

The GitHub "network graph" is most known for exploring fork activity, but even in a single repo scenario with no forks you can still use it as a cudgel to show some idea of the complex graph if you need to stick with GitHub provided visualization tools. (It doesn't help that several UX redesigns have done nothing but bury the network graph, but it's still around.)

You might think about investing in a copy of a client that puts the graph up front for that developer, such as GitKraken.

Though I've actually had good success with a tool that is free and already out of the box in most git installs: gitk. gitk is ugly, but it gets the idea across and is easier to teach most developers to use than trying to get them to remember to add the --graph flag to git log. (Though adding a good alias for `git log --graph` or some further relative like `git log --graph --oneline` and encouraging them to use the alias instead is also another option.)

Post reply on HN