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

From: Duy Nguyen <pclouds@gmail.com>
Date: Jun 8, 2013, 12:34 UTC
Message-ID: <CACsJy8CQRWU0mFLVD6RrpzJiHBH=9zFwf5xDo7UhGW6A-OAzuw@mail.gmail.com>
In-Reply-To: <CAMP44s2fP4_=HtOsuwmxXG8qmp8CmpgEhz=BJFOFZxsTf_3gcQ@mail.gmail.com>

On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 18 quoted lines

> On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>>>> 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?
>>
>> And while we are at "why not", why don't you fork git?
>
> That's not an answer.

Neither is "Why not?"

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

what code besides sequencer.c?

> until libgit.a == libgit2. Done.

Read up about the introduction of libgit2, why it was created in the first place instead of moving a few files around renaming libgit.a to libgit2.a. Unless you have a different definition of "==" than I do. -- Duy