On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> 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? > What do we gain from this? Organization. > A lot of code in libgit.a is only used by builtin commands, > e.g. fetch-pack.c, should we move it to? Yes. > 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. 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. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html