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