Git is extremely easy to "self host". What makes things complicated are the web interfaces around code hosting, and all their supposedly important features. These days, Prs, issues, forums, wikis and all that seem to be synonymous with "git", which is pretty weird.

▲

kace91 4 hours ago | parent | next [-]

What do you mean by supposedly?

The PR model is pretty much universal for a reason. I get why it is considered out of scope for core git, but it is by no means a weird fixation people have.

▲

lynx97 3 hours ago | parent [-]

Just send me an email with your branches URL, and I will pull from it. Thats pretty much what a Pull Request is.

▲

kace91 3 hours ago | parent | next [-]

>Thats pretty much what a Pull Request is.

Then you have to use email for the review conversation, make the discussion easily available to everyone involved and future devs, track manually which comment refers to which line of the diff due to lack of overlaying, manually ping to warn of updates, rely on manual quoting, no direct information on whether the CI pipeline succeeded...

To me that feels like writing code using only sed. It is possible, but it removes or makes convoluted an absurd degree of regular work.

▲

Jnr 3 hours ago | parent | prev | next [-]

You are correct, but integration with CI/CD and other services as a part of pull-request process in a modern platform is very convenient. I would not go back to e-mail. Especially since I can self host the whole platform like Gitea.

▲

hvb2 3 hours ago | parent | prev [-]

And the discussion about that PR goes in an email chain too?

You can pull, but having the back and forth documented along with the code is not a nice to have imho

	▲	spiffyk 3 hours ago \| parent \| next [-]
		Not that it fits everyone, but that is basically how the Linux kernel is being developed.
	▲	cyanydeez 3 hours ago \| parent \| prev \| next [-]
		Guys, guys, I'm just vibe coding here; just give me your credentials and mothers maiden name and I'll get it myself.
	▲	lynx97 3 hours ago \| parent \| prev [-]
		If it is not in git log, a few months down the drain, nobody will read the PR discussion anyway.

▲

rapnie 3 hours ago | parent | prev | next [-]

Because there isn't really a good name. In FOSS circles the name "code forge" is often used, and then OP might say "git-based code forge" instead. But both Github and Gitlab don't consider themself (and aren't) code forges. The term doesn't carry the load of the product positioning. So "hosting provider for git" is a pretty good description imho.

▲

ptsneves 4 hours ago | parent | prev [-]

Which is ironic because PR is definitely alien to git. There is no such git concept as a PR, nor git pr command.

Coming from a pure git workflow in mailing lists where branches, and commits(and associated diff and git am metadata) are the unit of work, I struggled to adapt into the PR concept in the beginning.

I liked to work with gerrit, where the unit of the review is the commit. This also ensured a nice little history and curation of the change set. The commit in github is not even in the main tab of the PR. It is like it is a second thought. Even in the review, reviewing by commit is awkward and discouraged.

	▲	_flux 3 hours ago \| parent [-]
		There are the commands git request-pull and git send-email to work with that workflow, though.