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

71–80 of 164 posts

Re: Git without a forge

#71

Post by keybored »

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!

git bundle works like git clone so there's nothing to worry about.

You simply don't know what you are talking about.

Re: Git without a forge

#72

Post by bo1024 »

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.

Yes, I've found Gitea very easy to self-host as well (I have two instances facing the public internet at the moment).

Re: Git without a forge

#73

Post by notpushkin »

mikepurvis wrote: post #59
nhanb wrote: post #50

Earlier quoted context omitted.

I once explored doing just that: https://github.com/nhanb/boast However I never got around to finishing it, mainly because I couldn't decide on where to stop: should I also generate commits from all non-master branches etc. I flirted with the idea of a browser-side repo viewer too, but re-implementing git packfile parsing in js didn't seem like something I'd want to spend my time on, so I moved on. Glad to see others…

That does get intense pretty quickly, if you're generating a source and commit/diff pages for every file * every commit. Probably just single commits would make the most sense and then a source browser for each branch. That said, JavaScript libgit2 is a thing [1], so doing it "properly" in a client app is totally possible. [1]: https://github.com/libgit2/libgit2/issues/4376 | https://github.com/petersalomonsen/wasm-g…

I’d go with a combined approach. Static pages for every file on master, JS for everything else. This way master branch loads instantly, but other branches (with diff, blame etc) are also available.

Hmmm, I might give it a go one day.

Re: Git without a forge

#75

Post by pabs3 »

kelnos wrote: post #67
rglullis wrote: post #11

Earlier quoted context omitted.

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 a…

The only way to do it is disable registration and have people contact you to allow registration.

Re: Git without a forge

#76

Post by rurban »

With git bug I'm independent on any forge, accounts and workflows there. I sync my bugs from github, but can also sync it to gitlab or codeberg.

Re: Git without a forge

#77

Post by throw94040 »

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.

That was on my android keyboard.

Re: Git without a forge

#78

Post by mikepurvis »

notpushkin wrote: post #73
mikepurvis wrote: post #59

Earlier quoted context omitted.

That does get intense pretty quickly, if you're generating a source and commit/diff pages for every file * every commit. Probably just single commits would make the most sense and then a source browser for each branch. That said, JavaScript libgit2 is a thing [1], so doing it "properly" in a client app is totally possible. [1]: https://github.com/libgit2/libgit2/issues/4376 | https://github.com/petersalomonsen/wasm-g…

I’d go with a combined approach. Static pages for every file on master, JS for everything else. This way master branch loads instantly, but other branches (with diff, blame etc) are also available. Hmmm, I might give it a go one day.

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

Re: Git without a forge

#79

Post by cortesoft »

chungy wrote: post #65
yellowapple wrote: post #57

Earlier quoted context omitted.

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 s…

I agree, and adding a `-a` to your git commit if you dont want to have to add all the changes is not much of an added burden for people who operate in the fossil way

Re: Git without a forge

#80

Post by cortesoft »

MaxBarraclough wrote: post #4

This reminds me of Drew DeVault's advocacy for the traditional email-driven git workflow. [0][1] (Drew is the creator of SourceHut, an email-oriented git forge.) I think his (Simon's) objection to git send-email emails could be addressed with better tooling, or better use of them. It's 'just' a matter of exporting the emails into a single mailbox file, right? (I'm not experienced with git's email-driven features.) It…

I think it is funny to think of the email-driven git workflow as 'traditional' when it had such a short period of time as the standard way of doing things with git.

Git was created in 2005, and Github was created in 2008. So we had 3 years of email-driven git and 17 years of Github style development.

Post reply on HN