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

61–70 of 164 posts

Re: Git without a forge

#61

Post by 418tpot »

andyferris wrote: post #33
zem wrote: post #23

Earlier quoted context omitted.

yes, but people have an email account already. if they could use that to interact with my git forge that would be ideal.

These days most every website has "log in with Google", "log in with Apple", "log in with Microsoft", etc which sort-of addresses the issue (ironically to this comment, "log in with GitHub" is also pretty common). A more generic federated identity system that everyone could use/operate would of course be 1000% better. But slightly orthogonal to forge/no forge.

I don't think it really addresses the issue because it still requires an account at one of the predetermined identity providers. With email I just need a domain and I can self host the rest if I really cared to.

It would be so much nicer if there was a federated way where I the user could specify any OAuth identity provider (even if it was e.g. a self hosted one) rather than the predetermined list dictated by the relying party.

Funnily enough someone recently asked me if I could comment on a Product Hunt post and I was unable to do so since they only allow sign in with Google, Twitter, Facebook, Apple or Linked in; I have none of these accounts and would rather not create any of them. Oh well.

Re: Git without a forge

#62

Post by brutal_chaos_ »

haswell wrote: post #51

The author talks about the effort of hosting something more heavyweight like Gitlab. Having recently decided to self-host a Gitea instance, I was happy to find how ridiculously easy it is to get this up and running. I'm not hosting this on the public Internet, so maybe it's not a fair comparison, but thought it was worth mentioning that there are lighter/easier forge options than Gitlab.

I do this as well. Act Runner is great, too, if you want CI. It can be finicky, but I'm running it on a Pi4, so not the best setup for that.

Re: Git without a forge

#63

Post by ndegruchy »

AceJohnny2 wrote: post #54
ndegruchy wrote: post #2

This is what I love about Fossil[1]. You get all of those extra tools (wiki, chat, forums, bug tracker) in the server that is also in the binary that you use to manage the repo. So, if you want to serve it, just `fossil server file.fossil` or serve a whole directory of them. Or, if you want, you can just `fossil ui` and muck around yourself, locally. The server supports SSH and HTTPS interactions for cloning and push…

(tongue-in-cheek:) This is what I hate about Fossil, you get all this extra cruft (wiki, chat, forums, bug tracker) that's a worse version than dedicated software for each. It really depends on what you're optimizing for.

Fair enough. I usually deny permissions to the features I don't care about if I'm pushing it up on the web. It's nice to have them there if I need them, though.

Re: Git without a forge

#64

Post by dgl »

johannes1234321 wrote: post #19
wahern wrote: post #17

> People can ‘git clone’ my code, and there’s a web-based browsing interface (the basic gitweb) for looking around without having to clone it at all. I host my own public Git repositories, but statically--read-only, no HTML views. I don't want to run any specialized server-side code, whether dynamic or preprocessed, as that's a security vector and system administration maintenance headache I don't want to deal with.…

I haven't looked into mich details of gibt's packing, but for a big repo you probably don't want a client to download it all nor do a huge amount of http range requests for being able to show the summary page. You think that would work well or would this need at least some caching layer?

Getting the tree (at the root) is only a few requests (get the refs or HEAD, get the relevant commit, get the tree ID from that). If pack files aren't involved then that's literally 3 requests. Pack files make this more complex, but careful caching and range requests could reduce that to as few as around 5-8 extra requests (doing binary searching via HTTP range requests). I don't think even libgit2 has APIs for range requests on pack files though, so this would need a special library (or patching libgit2...).

There's also various optimizations on the git side like bitmaps[1] and commit-graphs[2]. If this a bare repo on the server side it shouldn't be a problem to make sure it is in a particular format with receive hooks.

That's just displaying a file listing though. Displaying what GitHub displays with the last change of each file is more complex, maybe the commit graph could be used so the client wouldn't have to fetch everything itself.

  [1]: https://git-scm.com/docs/bitmap-format
  [2]: https://git-scm.com/docs/commit-graph

Re: Git without a forge

#65

Post by chungy »

yellowapple wrote: post #57
Lyngbakr wrote: post #46

Earlier quoted context omitted.

In terms of everyday workflow, does Fossil differ radically from git? If so, what's the learning curve like?

The biggest workflow differences I've noticed: - The repo normally lives outside of the worktree, so remembering to 'fossil new foo.fossil && mkdir foo && cd foo && fossil open ../foo.fossil' took some getting used to. Easy enough to throw into some 'fossil-bootstrap' script in my ~/.local/bin to never have to remember again. - For published repos, I've gotten in the habit of creating them directly on my webserver an…

> - Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'.

That'd be a deal breaker for me. Git's staging area is such a breath of fresh air compared to the old way (that fossil is doing), that it's one of the biggest reasons for me to switch to it. It's completely freeing to not have to worry about things being accidentally added to commits that I didn't want to have.

Re: Git without a forge

#66

Post by cryptonector »

Joker_vD wrote: post #28
throw94040 wrote: post #10

》The simplest kind of git bundle – a full bundle – is a whole git repository, wrapped up into a single file. Git repo can have executable code! Git hooks are shell commands stored in dir ".git/hooks" executed on events such as merge, commit... That is not duplicated by git clone, I am not sure about bundles. But I would be VERY careful to accept something like compressed git repo from anyone!

Sorry, did you have to use a Wide character? There is a Narrow version of it: ⟫ U+27EB MATHEMATICAL RIGHT DOUBLE ANGLE BRACKET.

Does it cause problems on mobile or something?

Re: Git without a forge

#67

Post by kelnos »

rglullis wrote: post #11
etaweb wrote: post #7

> In particular, your project automatically gets a bug tracker – and you don’t get a choice about what bug tracker to use, or what it looks like. If you use Gitlab, you’re using the Gitlab bug tracker. The same goes for the pull request / merge request system. With Forgejo (Codeberg) you can toggle features such as pull requests, issues, etc. You can also configure any external issue tracker or wiki apparently, thoug…

Forgejo (once federation is implemented) also fixes the main issue of forcing people to have an account at every forge.

It does solve that problem, but then creates a huge spam problem. Over at gitlab.xfce.org we are constantly fighting new spam accounts that get created daily. We've done all the recommended/paranoid things, like not allowing new accounts to fork or create repos until we manually give them permission (among other things), and we have a script that runs hourly to shut down suspicious accounts. But it's still nuts.

If anyone with an account on any other gitlab instance could automatically do things on our gitlab instance, it would be a nightmare. We'd probably disable federation if gitlab offered it.

Re: Git without a forge

#68

Post by kelnos »

zem wrote: post #12

as someone who finds the whole forge interface a massive improvement in git collaboration workflow I was fully prepared to find the author's arguments against a lightweight self hosted forge unconvincing. but the "need to create an account" is an extremely valid drawback, and one I do not have a good answer to.

> but the "need to create an account" is an extremely valid drawback, and one I do not have a good answer to.

I never find this to be a big deal. The friction to create a new account is usually pretty low. Type in my email address, let Firefox generate and save a secure password, maybe do email verification, and I'm in. If I'm willing to spend possibly hours crafting a patch to contribute to some software I like, followed by some code-review back-and-forth, the few minutes spent setting up an account is nothing.

Re: Git without a forge

#69

Post by kelnos »

andyferris wrote: post #33
zem wrote: post #23

Earlier quoted context omitted.

yes, but people have an email account already. if they could use that to interact with my git forge that would be ideal.

These days most every website has "log in with Google", "log in with Apple", "log in with Microsoft", etc which sort-of addresses the issue (ironically to this comment, "log in with GitHub" is also pretty common). A more generic federated identity system that everyone could use/operate would of course be 1000% better. But slightly orthogonal to forge/no forge.

I refuse to use those, because that means now my ability to log into this website is tied to my ability to log into the identity provider's website. I'd rather maintain control over that myself.

Re: Git without a forge

#70

Post by kelnos »

edfletcher_t137 wrote: post #58

> Also, I might as well come out and say this: one reason I don’t want to use Github is because it’s the most popular place to host your code. It's the goth subculture of software development! Because it's popular, it must be eschewed. Geez.

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.
Post reply on HN