5 ms·

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 workfl

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 better if I were contributing to something using lists.sr.ht and could just set the default list address for the project and not worry about it. I do also like being able to update an existing PR as I'm making rapid changes though, and just pushing up to whatever branch my PR references is also really nice. (It's, what, 5 keystrokes to push my latest changes to my remote for that branch? And that's assuming I don't already have the git status buffer open.) Applying a PR is also straightforward, which matters especially for newer users. Uh, you press a button. I'm all for decentralization, but this is the UX you're up against.

rectang 6y ago
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 branch lines of development. Give me `git log --graph`!
- pabs3 6y ago
  There are lots of graphical history viewers, I use gitk mostly and git-big-picture to get a graphical overview graph without individual commits. The gitg GUI from GNOME is fairly good too, and of course there are better tools for proprietary operating systems.
  - rectang 6y ago
    For local development, I'm actually content with what I get from the Git command line interface: I use a slightly customized variant of `git log --oneline --graph`. The problem is that I am often browsing the history of repositories hosted on Github via the Github web interface, along with other interactions such as searching through issues and PR history. Cloning a repo to my local machine and firing up gitk is a pretty inconvenient interruption of the web browsing experience.
- 0x0 6y ago
  Gitlab has a great graph view
- jlokier 6y ago
  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.
  - WorldMaker 6y ago
    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.)
- rakoo 6y ago
  > 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
- ClumsyPilot 6y ago
  This, a thousand times this. I fail to understand how such an established and well funded project can lack somethong so basic, so core to the entire system. <rant> Every time I see people doing a dance and paising billion dollar companies like netflix, uber or deliveroo, I check them out, realise that they lack most essential functionality: Deliveroo didn't have Search(!) For restaraunts for like a year Netflix will sell you a 4K plan, but if your system has 4K screen but does not satisfy their '4K requirements' it won't tell you that you aren't gonna get 4K or what you are missing. Uber outright used to lie about time to arrive, in London all taxis were always 4 minutes away. So I I often wonder, we pulled resources and finance in billions across the world, and this is the best we can do?
eeZah7Ux 6y ago
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.
- jillesvangurp 6y ago
  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?
arghwhat 6y ago
> 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/ 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.
- ryukafalz 6y ago
  > 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 to polish it to a mergeable state. Surely I'm not the only one who finds this useful, or the feature wouldn't exist. Furthermore, it's also helpful when collaborating on something that's not code via a PR. For example, I've used git to collaborate on documents; as far as I'm concerned it's much better to have a tight feedback loop between the comments I receive and the edits I make to the document. There's not one "right" way to word things, and I'm not necessarily the only one working on that document, I just happened to be the one to start it; allowing other people to suggest small edits to the document piecemeal more closely matches the kind of collaboration I'm actually looking for.
  - WorldMaker 6y ago
megous 6y ago
I once wrote a hook script for a company I work for that would send patch series e-mail when someone pushed a new tag into a shared repository, so I could comment on the changes just by replying to emailed patches. Cover letter was created from a message attached to a tag. So if someone wanted a review of some changes all that was necessary was to push their current status to a tag, which is a single command in git. No git-send-mail setup needed. It was quite nice middle ground, and didn't require me to use github/gitlab GUI. Being able to stay in neomutt for most communications was nice.

rectang 6y ago

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 branch lines of development. Give me `git log --graph`!

pabs3 6y ago
There are lots of graphical history viewers, I use gitk mostly and git-big-picture to get a graphical overview graph without individual commits. The gitg GUI from GNOME is fairly good too, and of course there are better tools for proprietary operating systems.
- rectang 6y ago
  For local development, I'm actually content with what I get from the Git command line interface: I use a slightly customized variant of `git log --oneline --graph`. The problem is that I am often browsing the history of repositories hosted on Github via the Github web interface, along with other interactions such as searching through issues and PR history. Cloning a repo to my local machine and firing up gitk is a pretty inconvenient interruption of the web browsing experience.
0x0 6y ago
Gitlab has a great graph view
jlokier 6y ago
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.
- WorldMaker 6y ago
  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.)
rakoo 6y ago
> 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
ClumsyPilot 6y ago
This, a thousand times this. I fail to understand how such an established and well funded project can lack somethong so basic, so core to the entire system. <rant> Every time I see people doing a dance and paising billion dollar companies like netflix, uber or deliveroo, I check them out, realise that they lack most essential functionality: Deliveroo didn't have Search(!) For restaraunts for like a year Netflix will sell you a 4K plan, but if your system has 4K screen but does not satisfy their '4K requirements' it won't tell you that you aren't gonna get 4K or what you are missing. Uber outright used to lie about time to arrive, in London all taxis were always 4 minutes away. So I I often wonder, we pulled resources and finance in billions across the world, and this is the best we can do?

eeZah7Ux 6y ago

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.

jillesvangurp 6y ago
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?

arghwhat 6y ago

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

ryukafalz 6y ago
> 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 to polish it to a mergeable state. Surely I'm not the only one who finds this useful, or the feature wouldn't exist. Furthermore, it's also helpful when collaborating on something that's not code via a PR. For example, I've used git to collaborate on documents; as far as I'm concerned it's much better to have a tight feedback loop between the comments I receive and the edits I make to the document. There's not one "right" way to word things, and I'm not necessarily the only one working on that document, I just happened to be the one to start it; allowing other people to suggest small edits to the document piecemeal more closely matches the kind of collaboration I'm actually looking for.
- WorldMaker 6y ago

megous 6y ago

I once wrote a hook script for a company I work for that would send patch series e-mail when someone pushed a new tag into a shared repository, so I could comment on the changes just by replying to emailed patches. Cover letter was created from a message attached to a tag. So if someone wanted a review of some changes all that was necessary was to push their current status to a tag, which is a single command in git. No git-send-mail setup needed. It was quite nice middle ground, and didn't require me to use github/gitlab GUI. Being able to stay in neomutt for most communications was nice.