Felipe Contreras felipe.contre...@gmail.com writes:
- There may be pieces of usefully reusable code buried in
builtin/*.o;
- By definition, any code (piece of data or function definition) in
builtin/*.o cannot be used in standalone binaries, because all of
builtin/*.o expect to
On Tue, Jun 11, 2013 at 12:33 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
- There may be pieces of usefully reusable code buried in
builtin/*.o;
- By definition, any code (piece of data or function definition) in
builtin/*.o cannot
Felipe Contreras felipe.contre...@gmail.com writes:
What are the examples you have in mind, code that we want to forbid
standalone from using?
init_copy_notes_for_rewrite(). Nothing outside the 'git' binary would
need that. If you disagree, show me an example.
Nothing would need that, if
On Tue, Jun 11, 2013 at 12:58 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
What are the examples you have in mind, code that we want to forbid
standalone from using?
init_copy_notes_for_rewrite(). Nothing outside the 'git' binary would
need
On Tue, Jun 11, 2013 at 11:06 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Moreover, if you are going to argue that we shouldn't be closing the
door [...]
Felipe, you saying if you are going to argue ... to anybody else is
kind of ironic.
Why is it every thread I see you in, you're
Felipe Contreras felipe.contre...@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
On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@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
On Tue, Jun 11, 2013 at 1:14 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Jun 11, 2013 at 11:06 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Moreover, if you are going to argue that we shouldn't be closing the
door [...]
Felipe, you saying if you are going to
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@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
On Tue, Jun 11, 2013 at 2:24 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Moreover, if you are going to argue that
Linus Torvalds torva...@linux-foundation.org writes:
This whole thread has been one long argument about totally pointless
things that wouldn't improve anything one way or the other. It's
bikeshedding of the worst kind. Just let it go.
The proposal to move sequencer.c to builtins/sequencer.c
On Tue, Jun 11, 2013 at 2:59 PM, Junio C Hamano gits...@pobox.com wrote:
Linus Torvalds torva...@linux-foundation.org writes:
This whole thread has been one long argument about totally pointless
things that wouldn't improve anything one way or the other. It's
bikeshedding of the worst kind.
On Sun, Jun 09, 2013 at 07:30:31PM +0200, Vincent van Ravesteijn wrote:
I think that libgit.a should contain all code to be able to carry out
all functions of git. The stuff in builtin/ is just a command-line
user interface. Whether or not sequencer should be in builtin depends
on whether the
On Mon, Jun 10, 2013 at 4:45 PM, Jeff King p...@peff.net wrote:
That is what libgit.a _is_ now. I do not mean to imply any additional
judgement on what it could be. But if the goal is to make libgit.a
functions that programs outside git.git would want, and nothing else,
we may want to
On Mon, Jun 10, 2013 at 04:52:57PM -0500, Felipe Contreras wrote:
On Mon, Jun 10, 2013 at 4:45 PM, Jeff King p...@peff.net wrote:
That is what libgit.a _is_ now. I do not mean to imply any additional
judgement on what it could be. But if the goal is to make libgit.a
functions that
On Mon, Jun 10, 2013 at 5:06 PM, Jeff King p...@peff.net wrote:
On Mon, Jun 10, 2013 at 04:52:57PM -0500, Felipe Contreras wrote:
On Mon, Jun 10, 2013 at 4:45 PM, Jeff King p...@peff.net wrote:
That is what libgit.a _is_ now. I do not mean to imply any additional
judgement on what it
Jeff King p...@peff.net writes:
My general impression of the goal of our current code organization is:
1. builtin/*.c should each contain a single builtin command and its
supporting static functions. Each file gets linked into git.o to
make the main git executable.
Correct; that
On Mon, Jun 10, 2013 at 6:41 PM, Junio C Hamano gits...@pobox.com wrote:
For the particular case of trying to make sequencer.o, which does
not currently have dependencies on builtin/*.o, depend on something
that is in builtin/notes.o, the link phase of standalone that wants
anything from
Felipe Contreras felipe.contre...@gmail.com writes:
*1* ... which is a very reasonable thing to do. But moving
sequencer.o to builtin/sequencer.o is *not* the way to do this.
By now we all know what is the *CURRENT* way to do this; in other
words, the status quo, which is BTW all messed
On Mon, Jun 10, 2013 at 7:04 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
*1* ... which is a very reasonable thing to do. But moving
sequencer.o to builtin/sequencer.o is *not* the way to do this.
By now we all know what is the
On Mon, Jun 10, 2013 at 8:53 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
And I do not see the reason why builtin/*.o should not depend on
each other. It is not messed up at all. They are meant to be
linked into a single binary---that is what being
Felipe Contreras wrote:
The plan is simple; make libgit.a a proper library, starting by
clarifying what goes into libgit.a, and what doesn't. If there's any
hopes of ever having a public library, it's clear what code doesn't
belong in libgit.a; code that is meant for builtins, that code
On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
Felipe Contreras wrote:
The plan is simple; make libgit.a a proper library, starting by
clarifying what goes into libgit.a, and what doesn't. If there's any
hopes of ever having a public library, it's clear what code
On Sun, Jun 9, 2013 at 10:12 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
Felipe Contreras wrote:
The plan is simple; make libgit.a a proper library, starting by
clarifying what goes into libgit.a, and what doesn't. If
On Sun, Jun 9, 2013 at 9:56 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
The plan is simple; make libgit.a a proper library, starting by
clarifying what goes into libgit.a, and what doesn't. If there's any
hopes of ever having a public library, it's clear what
On Sun, Jun 09, 2013 at 10:40:32AM -0500, Felipe Contreras wrote:
On Sun, Jun 9, 2013 at 10:12 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
Felipe Contreras wrote:
The plan is simple; make libgit.a a proper library,
On Sun, Jun 9, 2013 at 11:02 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jun 09, 2013 at 10:40:32AM -0500, Felipe Contreras wrote:
On Sun, Jun 9, 2013 at 10:12 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
Felipe
John Keeping wrote:
How is it only useful for builtin commands? By that logic everything
belongs in builtin/ because it's all only used by builtin commands (I
realise that is what you're arguing towards).
sequencer.c is merely a common API for builtins to invoke
continuations: i.e. stop the
On Sun, Jun 09, 2013 at 11:22:06AM -0500, Felipe Contreras wrote:
On Sun, Jun 9, 2013 at 11:02 AM, John Keeping j...@keeping.me.uk wrote:
But we make a distinction between things that are specific to one
command (especially argument parsing and user interaction) and more
generally useful
On Sun, Jun 9, 2013 at 12:03 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
John Keeping wrote:
Calling across from one builtin/*.c file to another is just as wrong as
calling into a builtin/*.c file from a top-level file but the build
system happens not to enforce the former.
So
Ramkumar Ramachandra wrote:
So libgit.a is a collection of everything that is shared between
builtins?
That is not to say that we shouldn't share things between builtins.
We can do it in builtin/lib.a, as Felipe has demonstrated here [1].
[1]:
Op 9-6-2013 17:40, Felipe Contreras schreef:
On Sun, Jun 9, 2013 at 10:12 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
Felipe Contreras wrote:
The plan is simple; make libgit.a a proper library, starting by
clarifying what
On Sun, Jun 09, 2013 at 12:13:41PM -0500, Felipe Contreras wrote:
On Sun, Jun 9, 2013 at 12:03 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
John Keeping wrote:
Calling across from one builtin/*.c file to another is just as wrong as
calling into a builtin/*.c file from a top-level
On Sun, Jun 9, 2013 at 12:30 PM, Vincent van Ravesteijn v...@lyx.org wrote:
Op 9-6-2013 17:40, Felipe Contreras schreef:
On Sun, Jun 9, 2013 at 10:12 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
Felipe Contreras wrote:
On Sun, Jun 9, 2013 at 12:32 PM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jun 09, 2013 at 12:13:41PM -0500, Felipe Contreras wrote:
On Sun, Jun 9, 2013 at 12:03 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
John Keeping wrote:
Calling across from one builtin/*.c file to another
There's no libgit, and there will never be, every object file in Git is
the same, and there's wish to organize them in any way; they are *all*
for the 'git' binary and its builtin commands.
So let's shatter any hopes of ever having a library, and be clear about
it; both the top-level objects
Felipe Contreras wrote:
There's no libgit, and there will never be, every object file in Git is
the same, and there's wish to organize them in any way; they are *all*
for the 'git' binary and its builtin commands.
Nice joke patch to illustrate your point ;)
On a more serious note, please be a
On Sat, Jun 8, 2013 at 1:02 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
There's no libgit, and there will never be, every object file in Git is
the same, and there's wish to organize them in any way; they are *all*
for the 'git' binary and its builtin commands.
38 matches
Mail list logo
