On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen <pclo...@gmail.com> wrote:
> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
> <felipe.contre...@gmail.com> wrote:
>> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen <pclo...@gmail.com> wrote:
>>> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
>>> <felipe.contre...@gmail.com> wrote:
>>>> This code is only useful for cherry-pick and revert built-ins, nothing
>>>> else, so let's make it a builtin object, but make sure 'git-sequencer'
>>>> is not generated.
>>> As you can see, the convention is builtin/foo.c corresponds to git-foo
>>> (and maybe more). Why make an exception for sequencer?
>> Why not?
> And while we are at "why not", why don't you fork git?

That's not an answer.

>>> I ask because I moved
>>> fetch-pack from builtin out because of linking issues and I don't want
>>> the same happen to sequencer.c.
>> I'm sure those linking issues can be solved.
> Yeah, I scratched my head for hours and finally gave in. Maybe you are
> better at the toolchain than me.

I gave it a try, but transport.c needs fetch_pack(), and transport
does belong in libgit.a, so fetch_pack() belongs there too.

This is not the case for sequencer.c.

>> I don't see why libgit.a couldn't eventually be the same as libgit2.
>> We need better organization tough (e.g. builtins/lib.a).
>> If you are arguing favor of a more messy setup, then we should link
>> all the builtin/*.o to libgit.a, because the current situation just
>> doesn't cut it.
>> For example, init_copy_notes_for_rewrite() cannot be accessed by
>> sequencer.c, and while it's possible to move that function (and
>> others) to libgit.a, it doesn't make sense, because it can only be
>> used by builtins.
> libgit.a is just a way of grouping a bunch of objects together, not a
> real library

That's what a library is.

> and not meant to be. If you aim something more organized,
> please show at least a roadmap what to move where.

I already did that; we move code from libgit.a to builtin/*.o until
libgit.a == libgit2. Done.

Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to