Re: [PATCH 2/2] Move sequencer to builtin

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Jun 8, 2013, 10:14 UTC
Message-ID: <CAMP44s29GiGJq3wyXAzJNo0FJY+Vbgd18bpBJMYQ47h-3M6sWA@mail.gmail.com>
In-Reply-To: <CACsJy8AMMCWSFC6EUHAgZdDA7E1kSPE3ZO6qGvS+WGji-di=Rw@mail.gmail.com>

On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen <pclouds@gmail.com> wrote:

Show 8 quoted lines

> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
> <felipe.contreras@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?

> What do we gain from this?

Organization.

> A lot of code in libgit.a is only used by builtin commands,
> e.g. fetch-pack.c, should we move it to?

Yes.

> 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.

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.

-- 
Felipe Contreras