Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git without a forge

chiark.greenend.org.uk

Post reply on HN
Print view View original

151–160 of 164 posts

Re: Git without a forge

#151

Post by bjackman »

imiric wrote: post #137
bjackman wrote: post #111

Earlier quoted context omitted.

No there are no standardised tools. There is Patchwork which can help with managing the review workload and can also provide some CI feedback, some subsystems use that with some succcess, other's don't. It's not really something an individual can adopt so if you're working in an area that doesn't use it you're out of luck. There is also Patchew which I've never tried. But overall everyone just has their own individua…

> No there are no standardised tools. Why would you expect there to be a standardised set of tools used by the largest distributed project in the world? Do you think that this would be possible to enforce globally in a way that makes everyone happier to contribute? You mentioned two tools that are used by some subsystems. b4[1] is another one, and more are listed here[2]. So there _is_ tooling around it that works fo…

I use b4, it largely solves sending code. It doesn't help with reviews though. (b4 shazam makes the manual application of patches to prepare a git-range-diff a bit easier but it's still basically a half baked process. It's fundamentally harder to to review patches than to review Git commits, a few thousand lines of Python won't make that reality go away).

> As long as you can send and receive email, you can contribute.

Sending and receiving email has so many barriers! The Linux Foundation literally has to manage a mail server that people who can't get access to a working mail setup can use! Saying that email is a sensible lowest common denominator is crazy. The reality of it is that the kernel community is majorly dependent on GMail and GMail isn't even a good mail service for the job!

Using a git forge is dramatically easier to use and easier to set up, host and maintain.

However, AFAIK there isn't a forge that exists today that can actually meet the kernel's needs though. Switching to one would be a significant project. (But if the core maintainers wanted it, it would be very feasible).

[0] https://korg.docs.kernel.org/linuxdev.html

Re: Git without a forge

#152

Post by Aeolun »

jlarcombe wrote: post #116
Aeolun wrote: post #82

The only thing I can ever think of while reading these things is: Why? What could possibly possess you to want to review and apply patches through email? The whole mentality is just utterly foreign to me.

the author explains his reasons in considerable detail in the article...

Not far enough up that I wasn’t put off reading any further before I got to it.

Re: Git without a forge

#153

Post by cryptonector »

Joker_vD wrote: post #148
cryptonector wrote: post #142

Earlier quoted context omitted.

Yes, that could be annoying. I'd imagine that you'd want to use only fixed-width fonts in a terminal emulator (where double-widths are ok, but not 1.5). If a fixed-width font has any glyphs other than single- and double-width then that's a problem.

Most fixed-width fonts don't have glyphs for all of the Unicode code points, you see, so the terminal emulators use fallback fonts, and it's seems to almost impossible to learn what fonts exactly they use. I believe in my case those 1.5-width glyphs were taken from the DejaVu Sans font (the non-mono version) but it's hard to be certain. In any case, I was quite tilted that I had to go back to using 10♠, K♦ etc. inste…

Oh dear. I did not know this. I don't usually browse the web using elinks or such, but maybe if I did I'd know. Or if I wrote TUIs, like you do. I do use TUI MUAs, but I rarely run into this problem there.

Re: Git without a forge

#154

Post by imiric »

bjackman wrote: post #151
imiric wrote: post #137

Earlier quoted context omitted.

> No there are no standardised tools. Why would you expect there to be a standardised set of tools used by the largest distributed project in the world? Do you think that this would be possible to enforce globally in a way that makes everyone happier to contribute? You mentioned two tools that are used by some subsystems. b4[1] is another one, and more are listed here[2]. So there _is_ tooling around it that works fo…

I use b4, it largely solves sending code. It doesn't help with reviews though. (b4 shazam makes the manual application of patches to prepare a git-range-diff a bit easier but it's still basically a half baked process. It's fundamentally harder to to review patches than to review Git commits, a few thousand lines of Python won't make that reality go away). > As long as you can send and receive email, you can contribut…

> It's fundamentally harder to to review patches than to review Git commits

I'm not familiar with kernel development, but after you pull the patches locally, can't you simply review the commits via `git diff` or with whatever viewer you use? This is how I often review code when using GitHub. I only use the GH interface for sending my comments, which is what email in the kernel workflow is for.

The only thing a web-based tool is helpful for is for grouping discussions, and being able to reference or find them later. This might be more tedious with typical web-based email UIs, but most offer some kind of threading and search support, so it can't be that bad.

> Sending and receiving email has so many barriers!

Email has many problems, but I don't see barriers to using it as one of them. There are literally thousands of providers to choose from that could be suitable for sending and receiving patches.

> The Linux Foundation literally has to manage a mail server that people who can't get access to a working mail setup can use!

linux.dev is not managed by the Linux Foundation but by Migadu. It's only offered as a convenience service for people on corporate networks who have no control over their email. They could just as well choose to use another provider.

> Using a git forge is dramatically easier to use and easier to set up, host and maintain.

You contradict this right in your next sentence. You're right that maintaining a centralized system at this scale would be a daunting task. Email being decentralized avoids this problem altogether.

The thing is that a "forge" provides several loosely-related services.

Sharing code is a basic one that Git already does quite well over HTTPS and SSH. What I don't understand is why the patches simply aren't shared this way instead of using email as the medium. The problems outlined in the original article are very real. Kernel development could follow a similar suggested model where URLs to pull from are shared instead, while keeping email strictly for reviews and discussions. This way everyone would be free to choose where they want to host their fork, and maintainers can simply pull from it. But I digress...

The other things forges are used for are code reviews, CI, bug tracking, planning, etc. It's debatable how helpful any of these services are, and many developers would have their own preference. You might like Gerrit, but that's not a universal opinion. And I think most developers would agree that code reviewing in GitHub or Gitlab is painful. If it was up to me, I would choose a tool like git-appraise instead, but I'm stuck with GitHub because that's what the teams I've worked on have preferred.

So my point is that email is likely not the best choice for this, but it's a reasonable one that's flexible enough to be usable by anyone. Forcing any other tool on everyone would likely displease an equal or greater amount of contributors, while also introducing maintenance and reliability problems.

Re: Git without a forge

#155

Post by ackyshake »

mcherm wrote: post #117
ackyshake wrote: post #87

> A particular thing I don’t like about git forge websites is the way they make you create an account. Exactly. I used to have a GitHub account but as soon as it got bought out by Microsoft, I was gone. I still refuse to create an account, even though there have been bugs I wanted to report or patches I wanted to contribute. Maybe some maintainers still have email addresses on their profile, many don't. Even if they…

I am curious -- what is your concern about creating an account? Is it security? Privacy? The need to keep track of it?

Security/privacy yeah. I don't do business with Twitter/Facebook for the same reason. In the case of GitHub, if I want to contribute something, I am going to do it volitionally, knowing they will do whatever they want with it.

Creating an account just locks you in, when the alternative exists or existed before. SourceHut proves this is possible. Why not allow non-accounts to contribute?

Re: Git without a forge

#156

Post by ackyshake »

TiredOfLife wrote: post #134
ackyshake wrote: post #87

> A particular thing I don’t like about git forge websites is the way they make you create an account. Exactly. I used to have a GitHub account but as soon as it got bought out by Microsoft, I was gone. I still refuse to create an account, even though there have been bugs I wanted to report or patches I wanted to contribute. Maybe some maintainers still have email addresses on their profile, many don't. Even if they…

How are you posting on HN without an account?

It's a good point, I suppose, but it doesn't have to be so black-and-white. There are certain exceptions to this no-account rule of course, like for your bank.

Now, would HN be better without an account? I believe it would, why not? I like lurking (and sometimes commenting) on HN though so I feel like creating an account is valid. Also, HN works fine without JS and has no trackers, which does tend to get me to create an account.

Re: Git without a forge

#157

Post by adastra22 »

bigstrat2003 wrote: post #39
adastra22 wrote: post #8

The way he prefers patches to him being sent (git repo URL + branch name) is basically what a forge does. Why make it more complicated for your users?

Why should it matter what potential contributors might want the workflow to be, unless his goal is to maximize contributors? There's nothing wrong with prioritizing your own tools desires, as long as you accept that it might limit how many people want to get involved.

What I’m saying is that his own preferred workflow is the same. When you make a pull request, it shoots the maintainer an email with a link to the git branch. Literally the same thing.

Re: Git without a forge

#158

Post by neilv »

neilv wrote: post #45
agf wrote: post #26

Gotta plug the Portable Puzzle Collection, by the same author as this post: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/

I can't tell you how many waiting rooms, grocery checkout lines, and delayed public transit that his puzzle collection gotten me through. On every handheld and laptop starting with the Symbian-based Nokia E61.

I even included SGT's puzzle collection in a Linux distro that was optimized for small size (but the puzzles were important)! :)

https://www.neilvandyke.org/lildeb/

Re: Git without a forge

#159

Post by freeopinion »

tylersmith wrote: post #92
kelnos wrote: post #70

Earlier quoted context omitted.

You conveniently left out the justification for that statement: because the author believes monocultures are bad, and doesn't want to support them. I think that's entirely reasonable, and characterizing it as "goth subculture" is dishonest.

> monocultures are bad, and doesn't want to support them is just > it's popular, it must be eschewed. after a chatgpt pass

Chatgpt can turn one into the other. But that doesn't mean they are the same thing.

You are right to be mindful of the similarities. But it could be a mistake to be dismissive of the deeper thinking that might be behind the statement if it isn't just AI spew.

Re: Git without a forge

#160

Post by mikepurvis »

notpushkin wrote: post #93
mikepurvis wrote: post #78

Earlier quoted context omitted.

Would the js pages really take much longer to load than static? Fetching a few packfiles and hydrating a template should be very fast.

Probably. We’re looking at three roundtrips here: one to fetch the HTML, one for the JS, and at least one for the packfiles (and that’s if you can do that in parallel). If the latency is high, the result can be... not great. HTTP/2 should help with this a bit, but it’s better to not have this problem at all IMO. Of course, there’s also the argument that if you’re self-hosting a repo, you’re more likely to care about…

If you render the repo home/tree/readme statically but serve the JS application upfront with that, then successive clicks into files/commits/diffs will only have to pull packfiles, and then only if the content isn't already present locally. Packfiles are obviously immutable so they can be set for infinite caching, which should mean that even successive visits could be pretty speedy.
Post reply on HN