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? >> 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. Yeah, I scratched my head for hours and finally gave in. Maybe you are better at the toolchain than me. > 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. libgit.a is just a way of grouping a bunch of objects together, not a real library and not meant to be. If you aim something more organized, please show at least a roadmap what to move where. -- 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
