💾 Archived View for gemi.dev › gemini-mailing-list › 001009.gmi captured on 2024-05-26 at 17:08:22. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-12-28)

-=-=-=-=-=-=-

Git Forges

1. Jonathan McHugh (indieterminacy (a) libre.brussels)

Hello all,

I have been deliberating regarding which git forge tool most compliments 
Gemini's protocol.

Naturally, web frontends such as Cgit are a product of legacy thinking - 
to serve git in a HTTP environment.

I do agree with Anna "CyberTailor", that Cgit outputting Gemini would be 'poggers'
=> https://lists.zx2c4.com/pipermail/cgit/2021-April/004633.html

Alas, I equally am not so well positioned to adapt the HTTP coding in C
=> https://git.zx2c4.com/cgit/tree/html.c
=> https://git.zx2c4.com/cgit/tree/html.h

However, I have been looking into Gitolite further:
=> https://gitolite.com/gitolite Homepage
=> https://guix.gnu.org/manual/en/html_node/Version-Control-Services.html 
Guix OS' service configuration settings

# Gemini Advantages with regards to Gitolite

the most of clustered and decentralised forges.

# Classical Advantages


# Points of Concern

federating (eventual
consistency?)

# Points of Inquiry

lots of self hosters within the Gemini comm
unity, Im not sure Ive seen people go without HTTP services


Its also worth referencing Alan's recent comments regarding his hopes of 
Archlinux stype Wikis for serving Gemini interests 
=> gemini://gemi.dev/gemini-mailing-list/messages/007060.gmi Re: More Awesome Gemini

As well as Solderpunk's thoughts regarding the growth of the community at 
the start of 2021
=> gemini://gemi.dev/gemini-mailing-list/messages/004642.gmi [announce] Gemini in 2021

Any thoughts?

====================
Jonathan McHugh
indieterminacy@libre.brussels

Link to individual message.

2. Rohan Kumar (seirdy (a) seirdy.one)

On Wed, Sep 01, 2021 at 04:25:02PM +0000, Jonathan McHugh wrote:
> I have been deliberating regarding which git forge tool most compliments 
Gemini's protocol.
> Naturally, web frontends such as Cgit are a product of legacy thinking - 
to serve git in a HTTP environment.
> I do agree with Anna "CyberTailor", that Cgit outputting Gemini would be 'poggers'
> => https://lists.zx2c4.com/pipermail/cgit/2021-April/004633.html

Indeed, anybody who could pull this off would be a certified PogChamp™.

That being said, I'm not certain that this should be of high priority. I 
think a good Gemini landing page for a project is probably better. A 
Gemini export of `git log` might be worthwhile, but the rest can still be 
better seen with a git clone.

Expecting users to do a `git clone` for very large repos is unrealistic, 
of course. However, Gemini is not optimized for very large files with many 
thousands of lines. This isn't quite the "DocuWeb" niche that Gemini occupies.

Gemini is an *alternative* to the WWW, not a *replacement*. Bringing 
complete git frontends to Gemini doesn't seem as good as simply making 
good landing pages for projects. Sample content in such a landing page may include:

- the README
- Repositories with names, links, sizes, and last-commit dates, and 	clone addresses.
- Links to the issue trackers and discussion platforms (e.g. lists, 	chatrooms)
- License summary (could be in README)
- maybe a link to a paginated Gemini export of `git log`.

In other words, not a *complete* Git experience, but just what's appropriate for Gemini.

-- /Seirdy

Link to individual message.

---

Previous Thread: mime types on gmnisrv

Next Thread: Re: Gemini Digest, Vol 26, Issue 3