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.
Git email flow vs. GitHub flow
41–50 of 177 posts
Re: Git email flow vs. GitHub flow
#42I 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…
Re: Git email flow vs. GitHub flow
#43For 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
#44I 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…
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
#45I 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 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
#46Reading 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.
Re: Git email flow vs. GitHub flow
#47I 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…
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
#48I 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.
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
#49I 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…
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- 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