On Sat, Jun 8, 2013 at 7:34 AM, Duy Nguyen <pclo...@gmail.com> wrote:
> On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras
> <felipe.contre...@gmail.com> wrote:
>> 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.
> Neither is "Why not?"
The answer is the rest of the e-mail.
>>> 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?
A roadmap doesn't require code. If you truly think that there's
nothing else that is specific to builtins; alias.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.
Are you being obtuse on purpose? It doesn't matter how different
libgit.a and libgit2 currently are, there's always a path from one
code-base to another. Unless libgit2 has code for builtin commands,
the first step would invariably be to move the code that is specific
for builtins to builtin/*.o.
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