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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.