git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] cgit in git?

From
Johan Herland <johan@herland.net>
Date
Dec 11, 2008, 22:40 UTC
Message-ID
<200812112340.57223.johan@herland.net>
In-Reply-To
<8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com>
On Thursday 11 December 2008, Lars Hjemli wrote:
Show 34 quoted lines
> Background: I've been asked by the fedora project how to package cgit.
> The problem is basically that cgit is designed to be statically linked
> with a specific git release (i.e. libgit.a and xdiff/lib.a).
>
> When manually building cgit from a tarball this isn't a problem:
> 'make get-git' will download the required git sources from kernel.org.
> But the buildsystem/policy used by the fedora project does not allow
> network access during package builds, and since it is quite unlikely
> that the git package always will match the exact release needed by the
> cgit package, I only see four options:
> 1) the fedora project makes a 'git-for-cgit' package containing the
> needed release of the git sources
> 2) the cgit release tarballs includes the needed git sources
> 3) the cgit sources are subtree-merged into git
> 4) cgit is modified to link against libgit2
>
> Option 1 seems unlikely to happen since such a 'git-for-cgit' package
> would basically require the fedora project to support two git
> packages.
>
> Option 2 is doable but still requires the fedora project to support
> two git packages (but now the 'git-for-cgit' package is hidden inside
> the cgit source tree). The good thing about this option is that it
> only requires some minor modifications to the cgit releases.
>
> Option 3 would solve the problem for the fedora project but is not for
> me to decide - it might become an extra maintenance burden on the git
> maintainer and community.
>
> Option 4 is the correct solution but not a very practical one; it's
> currently hard to predict when libgit2 will be ready for general
> (c)git use.
>
> Personally I'd love for option 3 to happen, hence this rfc.

Option 5: Include cgit as a submodule in git.git. Then it's available to those who want it, but not cloned/built by default.

If that doesn't pan out, I also support option #3.

I've been a happy cgit user for a number of months, and have yet to find a single issue where cgit is not better than or equal to gitweb. I have nothing bad to say about gitweb per se, but cgit simply offers me a better user experience, not least because of its blazing speed.

Have fun!
...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Previous: Todd Zullinger
Message 7 of 7 in “[RFC] cgit in git?”
  1. Lars HjemliDec 11, 2008
  2. Miklos VajnaDec 11, 2008
  3. Jakub NarebskiDec 11, 2008
  4. Junio C HamanoDec 11, 2008
  5. Lars HjemliDec 11, 2008
  6. Todd ZullingerDec 12, 2008
  7. Johan HerlandDec 11, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.