Re: [PATCH 2/2] Move sequencer to builtin
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Jun 8, 2013, 13:28 UTC
- Message-ID
- <CAMP44s0EVESLfRUw7Aqz6VjXELcRG-6cETpcROTZXmPjU-Y8ig@mail.gmail.com>
- In-Reply-To
- <CACsJy8CQRWU0mFLVD6RrpzJiHBH=9zFwf5xDo7UhGW6A-OAzuw@mail.gmail.com>
On Sat, Jun 8, 2013 at 7:34 AM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 22 quoted lines
> On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras > <felipe.contreras@gmail.com> wrote: >> 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?"
The answer is the rest of the e-mail.
Show 6 quoted lines
>>> 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.
Show 5 quoted lines
>> 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.
-- Felipe Contreras