git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, Vincent van Ravesteijn <vfr@lyx.org>,
	John Keeping <john@keeping.me.uk>,
	Ramkumar Ramachandra <artagnon@gmail.com>,
	git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Duy Nguyen <pclouds@gmail.com>
Subject: Re: [PATCH] build: get rid of the notion of a git library
Date: Tue, 11 Jun 2013 14:49:39 -0500	[thread overview]
Message-ID: <CAMP44s0M6Jf_=bL+X06t7Vam+WypL_3JAt1odBkXCpMgqANDiQ@mail.gmail.com> (raw)
In-Reply-To: <7vobbca1sr.fsf@alter.siamese.dyndns.org>

On Tue, Jun 11, 2013 at 2:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> Moreover, if you are going to argue that we shouldn't be closing the
>>>> door, then why not link ./builtin/*.o to libgit.a?
>>>
>>> Huh?  It does not make any sense.  builtin/*.o files have cmd_foo()
>>> that are expected to be called from git.c::main(), but libgit.a
>>> files are linked with no constraints whose main() they are linking
>>> with.
>> ...
>>> That is exactly why I said that builtin/*.o should be refactored to
>>> pick "does not have to be in builtin" bits, which will result in a
>>> better division of labor.  Reusable bits should live in the library,
>>> while a particular implementation of command remain in builtin/*
>>> that utilize the reusable bits.
>>>
>>> You still haven't justified why we have to _forbid_ any outside
>>> callers from calling copy_notes_for_rewrite().
>>
>> Because only builtins _should_ use it.
>
> And there is no justification behind that "_should_" claim; you are
> not making any technical argument to explain it.

The first argument of init_copy_notes_for_rewrite() is the name of the
builtin command. There hardly could be any more justification.

>> I asked you for an example, and
>> you said a hypothetical standalone 'git-filter-branch' might use it,
>
> Of course it has to be hypothetical; I already said with the current
> code no standalone does use it---it is not arranged to be doable so
> there is no user.  If you want to have examples of future possible
> callers, they have to be hypothetical---the future by definition
> hasn't happened.  But that does not mean hypothetical is impractical
> nor useless.

So? It's still hypothetical, which is what I said. What are you
complaining about? About the fact that I made a correct assessment?

> There are out-of-tree programs like cgit that will not be built-in
> but already link with libgit.a.  Moving things that can be used by
> outside people out of builtin/*.o to libgit.a would allow uses that
> you and I cannot imagine offhand.  I do not see a reason for us to
> forbid a filter-branch replacement out of tree as a standalone.

Yeah, I already ran that argument, and you conveniently chose to
escape the next logical conclusion that I already put forward:

--- a/Makefile
+++ b/Makefile
@@ -990,6 +990,8 @@ BUILTIN_OBJS += builtin/verify-pack.o
 BUILTIN_OBJS += builtin/verify-tag.o
 BUILTIN_OBJS += builtin/write-tree.o

+LIB_OBJS += $(BUILTIN_OBJS)
+
 GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
 EXTLIBS =

I don't think that's the right direction.

> I do not see a point in continuing to discuss this (or any design
> level issues) with you.  You seem to go into a wrong direction to
> break the design of the overall system, not in a direction to
> improve anything.  I do not know, and at this point I do not care,
> if you are doing so deliberately to sabotage Git.  Just stop.

That's your opinion, and it's not shared by others (outside of the Git
project). If you were right and Git was moving in the right direction,
there would be no need for libgit2.

-- 
Felipe Contreras

  reply	other threads:[~2013-06-11 19:49 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-08 17:29 [PATCH] build: get rid of the notion of a git library Felipe Contreras
2013-06-08 18:02 ` Ramkumar Ramachandra
2013-06-08 18:22   ` Felipe Contreras
2013-06-09 14:56     ` Ramkumar Ramachandra
2013-06-09 15:12       ` John Keeping
2013-06-09 15:40         ` Felipe Contreras
2013-06-09 16:02           ` John Keeping
2013-06-09 16:22             ` Felipe Contreras
2013-06-09 16:42               ` John Keeping
2013-06-09 17:03                 ` Ramkumar Ramachandra
2013-06-09 17:12                   ` Ramkumar Ramachandra
2013-06-09 17:13                   ` Felipe Contreras
2013-06-09 17:32                     ` John Keeping
2013-06-09 17:45                       ` Felipe Contreras
2013-06-09 16:36             ` Ramkumar Ramachandra
2013-06-09 17:30           ` Vincent van Ravesteijn
2013-06-09 17:35             ` Felipe Contreras
2013-06-10 21:45             ` Jeff King
2013-06-10 21:52               ` Felipe Contreras
2013-06-10 22:06                 ` Jeff King
2013-06-10 22:22                   ` Felipe Contreras
2013-06-10 23:05                   ` Junio C Hamano
2013-06-10 23:41                     ` Junio C Hamano
2013-06-10 23:51                       ` Felipe Contreras
2013-06-11  0:04                         ` Junio C Hamano
2013-06-11  1:53                           ` Junio C Hamano
2013-06-11  4:15                             ` Felipe Contreras
2013-06-11 17:33                               ` Junio C Hamano
2013-06-11 17:41                                 ` Felipe Contreras
2013-06-11 17:58                                   ` Junio C Hamano
2013-06-11 18:06                                     ` Felipe Contreras
2013-06-11 18:14                                       ` Linus Torvalds
2013-06-11 19:15                                         ` Felipe Contreras
2013-06-11 19:59                                         ` Junio C Hamano
2013-06-11 20:12                                           ` Felipe Contreras
2013-06-12  0:12                                           ` [PATCH 0/3] Refactor useful notes functions into notes-utils.[ch] Johan Herland
2013-06-12  0:12                                             ` [PATCH 1/3] finish_copy_notes_for_rewrite(): Let caller provide commit message Johan Herland
2013-06-12 17:27                                               ` Junio C Hamano
2013-06-12  0:13                                             ` [PATCH 2/3] Move copy_note_for_rewrite + friends from builtin/notes.c to notes-utils.c Johan Herland
2013-06-12  0:32                                               ` Felipe Contreras
2013-06-12  7:10                                                 ` Johan Herland
2013-06-12 18:28                                                   ` Felipe Contreras
2013-06-12 19:14                                                     ` Johan Herland
2013-06-12 19:18                                                       ` Felipe Contreras
2013-06-13  6:45                                                     ` Andreas Krey
2013-06-13 13:13                                                       ` Felipe Contreras
2013-06-12 20:02                                               ` Junio C Hamano
2013-06-12  0:13                                             ` [PATCH 3/3] Move create_notes_commit() from notes-merge.c into notes-utils.c Johan Herland
2013-06-12 20:02                                             ` [PATCH 0/3] Refactor useful notes functions into notes-utils.[ch] Junio C Hamano
2013-06-12 20:11                                               ` Felipe Contreras
2013-06-13 17:24                                                 ` Junio C Hamano
2013-06-13 18:16                                                   ` Felipe Contreras
2013-06-13 18:50                                                     ` Felipe Contreras
2013-06-11 18:17                                       ` [PATCH] build: get rid of the notion of a git library Junio C Hamano
2013-06-11 19:01                                         ` Felipe Contreras
2013-06-11 19:24                                           ` Junio C Hamano
2013-06-11 19:49                                             ` Felipe Contreras [this message]
2013-06-11  4:04                           ` Felipe Contreras
2013-06-09 15:41       ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMP44s0M6Jf_=bL+X06t7Vam+WypL_3JAt1odBkXCpMgqANDiQ@mail.gmail.com' \
    --to=felipe.contreras@gmail.com \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=john@keeping.me.uk \
    --cc=jrnieder@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=vfr@lyx.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).