Re: [RFC] cgit in git?

From: Lars Hjemli <hjemli@gmail.com>
Date: Dec 11, 2008, 23:37 UTC
Message-ID: <8c5c35580812111537v1144c9fdy19f2a3cc56e2a04f@mail.gmail.com>
In-Reply-To: <7vwse6bart.fsf@gitster.siamese.dyndns.org>

On Thu, Dec 11, 2008 at 23:35, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> "Lars Hjemli" <hjemli@gmail.com> writes:
>
>> 2) the cgit release tarballs includes the needed git sources
>>
>> 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.
>
> I do not understand why this is any extra work for fedora.

I imagined that it could have a ripple-effect on package dependencies, i.e. the git release used by cgit could have subtle 'incompatibilities' with the real git package, but I really don't know the first thing about packaging so this is just a guess.

Show 6 quoted lines

> Instead of
> running "make get-git" and then running your build procedure, they need to
> just run your build procedure because you now ship your source with the
> matching version of the git source, which sounds like the right thing to
> me.  You do not install anything from the contained git.git area (we do
> not do shared objects, nor public header files) to the end product, right?

Right.

Show 5 quoted lines

> Doesn't cgit bind git.git as a subproject at the source level?  I would
> expect that the most natural release tarball for such a project would be a
> single tarball that has both the superproject itself _and_ the submodules
> it contains already extracted, iow, the state of your tree after you run
> "make get-git".

Your expectation makes sense to me, thanks for elaborating.

Seth: would such a self-contained tarball solve the problems on your end?

-- larsh