On Tue, Jun 11, 2013 at 2:59 PM, Junio C Hamano wrote:
> Linus Torvalds 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
Linus Torvalds 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 and then
adding a filter in
On Tue, Jun 11, 2013 at 2:24 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
Moreover, if you are going to argue that we shouldn't be closing the
door, then why not link ./builtin/*.o to
Felipe Contreras writes:
> On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano wrote:
>> Felipe Contreras 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 f
On Tue, Jun 11, 2013 at 1:14 PM, Linus Torvalds
wrote:
> On Tue, Jun 11, 2013 at 11:06 AM, Felipe Contreras
> 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.
On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano wrote:
> Felipe Contreras 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 expe
Felipe Contreras 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 linke
On Tue, Jun 11, 2013 at 11:06 AM, Felipe Contreras
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 being a dick and argui
On Tue, Jun 11, 2013 at 12:58 PM, Junio C Hamano wrote:
> Felipe Contreras 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 m
Felipe Contreras 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 you are talking abou
On Tue, Jun 11, 2013 at 12:33 PM, Junio C Hamano wrote:
> Felipe Contreras 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 bina
Felipe Contreras 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 link with git.o
On Mon, Jun 10, 2013 at 8:53 PM, Junio C Hamano wrote:
> Junio C Hamano 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 "built-in" is.
>>
>> A good w
On Mon, Jun 10, 2013 at 7:04 PM, Junio C Hamano wrote:
> Felipe Contreras 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
>> wo
Junio C Hamano 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 "built-in" is.
>
> A good way forward, the way it *SHOULD* be, is to slim the builtin/*.o
>
Felipe Contreras 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 up, because builtin
On Mon, Jun 10, 2013 at 6:41 PM, Junio C Hamano 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 revision.o (which
Junio C Hamano writes:
> Jeff King 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
Jeff King 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 is wha
On Mon, Jun 10, 2013 at 5:06 PM, Jeff King 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 wrote:
>>
>> > That is what libgit.a _is_ now. I do not mean to imply any additional
>> > judgement on what it could be. But if th
On Mon, Jun 10, 2013 at 04:52:57PM -0500, Felipe Contreras wrote:
> On Mon, Jun 10, 2013 at 4:45 PM, Jeff King 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 o
On Mon, Jun 10, 2013 at 4:45 PM, Jeff King 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 additionally s
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
On Sun, Jun 9, 2013 at 12:32 PM, John Keeping 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
>> wrote:
>> > John Keeping wrote:
>> >> Calling across from one builtin/*.c file to another is just as wrong as
>> >>
On Sun, Jun 9, 2013 at 12:30 PM, Vincent van Ravesteijn wrote:
> Op 9-6-2013 17:40, Felipe Contreras schreef:
>
>> On Sun, Jun 9, 2013 at 10:12 AM, John Keeping wrote:
>>>
>>> On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
Felipe Contreras wrote:
>
> The p
On Sun, Jun 09, 2013 at 12:13:41PM -0500, Felipe Contreras wrote:
> On Sun, Jun 9, 2013 at 12:03 PM, Ramkumar Ramachandra
> 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
Op 9-6-2013 17:40, Felipe Contreras schreef:
On Sun, Jun 9, 2013 at 10:12 AM, John Keeping 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, a
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]: http://article.gmane.org/gmane.comp.version-contr
On Sun, Jun 9, 2013 at 12:03 PM, Ramkumar Ramachandra
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 libgit.a is a col
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 libgit.a is a collection of everything that is shared between
builtins? Does that corr
On Sun, Jun 09, 2013 at 11:22:06AM -0500, Felipe Contreras wrote:
> On Sun, Jun 9, 2013 at 11:02 AM, John Keeping wrote:
> > But we make a distinction between things that are specific to one
> > command (especially argument parsing and user interaction) and more
> > generally useful features.
>
>
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 t
On Sun, Jun 9, 2013 at 11:02 AM, John Keeping 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 wrote:
>> > On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
>> >> Felipe Contreras wrote:
>> >> > The pla
On Sun, Jun 09, 2013 at 10:40:32AM -0500, Felipe Contreras wrote:
> On Sun, Jun 9, 2013 at 10:12 AM, John Keeping 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
> >
On Sun, Jun 9, 2013 at 9:56 AM, 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 doesn't
>>
On Sun, Jun 9, 2013 at 10:12 AM, John Keeping 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 there's any
>>
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 cod
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 bel
On Sat, Jun 8, 2013 at 1:02 PM, Ramkumar Ramachandra 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.
>
> Nice joke
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
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 (./*.
41 matches
Mail list logo
