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?
> What do we gain from this?
> A lot of code in libgit.a is only used by builtin commands,
> e.g. fetch-pack.c, should we move it to?
> 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.
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