From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Cc: Lars Hjemli <hjemli@gmail.com>,
Junio C Hamano <gitster@pobox.com>,
Seth Vidal <skvidal@fedoraproject.org>
Subject: Re: [RFC] cgit in git?
Date: Thu, 11 Dec 2008 23:40:57 +0100 [thread overview]
Message-ID: <200812112340.57223.johan@herland.net> (raw)
In-Reply-To: <8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com>
On Thursday 11 December 2008, Lars Hjemli wrote:
> 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
prev parent reply other threads:[~2008-12-11 22:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-11 21:48 [RFC] cgit in git? Lars Hjemli
2008-12-11 22:15 ` Miklos Vajna
2008-12-11 22:28 ` Jakub Narebski
2008-12-11 22:35 ` Junio C Hamano
2008-12-11 23:37 ` Lars Hjemli
2008-12-12 0:15 ` Todd Zullinger
2008-12-11 22:40 ` Johan Herland [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200812112340.57223.johan@herland.net \
--to=johan@herland.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hjemli@gmail.com \
--cc=skvidal@fedoraproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).