From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
Brandon Casey <drafnel@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>,
Shawn Pearce <sop@google.com>
Subject: Re: [PATCH 2/2] Move sequencer to builtin
Date: Sat, 8 Jun 2013 19:04:17 +0530 [thread overview]
Message-ID: <CALkWK0mw8=CMuyw5-E0fzh+c6Om_NCgHohqa_p=J_kw3UfJCJQ@mail.gmail.com> (raw)
In-Reply-To: <CACsJy8B=m95mpRn1dAwQZAvHRUeJVjKy1hKXv43EKX08ZODsDw@mail.gmail.com>
Duy Nguyen wrote:
> I _think_ the reason is because git was never written as a reusable
> library in mind from the beginning.
We cannot reverse-engineer intents, but I tend to agree with this. My
question is: so what? Is it impossible to do now?
> So global states and die() exist.
> Worse, "run once and let the OS clean eveything up at process exit"
> leads to some deliberate memory leak if it's made a library. See
> alloc.c for example. The internal API is not really designed to be
> usuable/stable as a library. All of these made it very hard to convert
> the current code base into a true library. So the effort was put into
> creating a new library instead, copying code from git code base over
> when possible.
I'm not saying that we can convert libgit.a into something that's
usable as a long-running process by production servers tomorrow. All
I'm saying is that it might be possible to get ruby (and possibly
other languages) to call into git-core, to make scripting more sane
than shell-spawning everything like brutes. I think this is what fc
is aiming at, atleast in the foreseeable future.
As far as long-running server-side implementations go, I think jgit is
the way forward (sop is more interested in that now, I believe).
libgit2 might work for GitHub now, but I don't know if they will be
forced to move to the jvm in the future.
> So instead of redoing it again, I think it's better that you help
> libgit2 guys improve it to the extend that git commands can be easily
> reimplemented. Then bring up the discussion about using libgit2 in C
> Git again.
Please look at the code in libgit2.git briefly. It's _very_ different
from git.git, and the amount of glue code that would be needed to
piece them together is unfathomable.
There are no git.git contributors committing to libgit2.git, or
vice-versa. libgit2 is primarily developed by vmg, cmn, and (more
recently) rb. It's quite an active project that's diverging from the
git.git design with every passing day.
next prev parent reply other threads:[~2013-06-08 13:35 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-07 22:16 [PATCH 0/2] Move sequencer Felipe Contreras
2013-06-07 22:16 ` [PATCH 1/2] log-tree: remove dependency from sequencer Felipe Contreras
2013-06-07 22:16 ` [PATCH 2/2] Move sequencer to builtin Felipe Contreras
2013-06-08 2:35 ` Duy Nguyen
2013-06-08 10:14 ` Felipe Contreras
2013-06-08 11:42 ` Duy Nguyen
2013-06-08 12:25 ` Felipe Contreras
2013-06-08 12:34 ` Duy Nguyen
2013-06-08 12:55 ` Ramkumar Ramachandra
2013-06-08 13:15 ` Duy Nguyen
2013-06-08 13:32 ` Felipe Contreras
2013-06-08 13:34 ` Ramkumar Ramachandra [this message]
2013-06-08 14:10 ` Felipe Contreras
2013-06-08 14:10 ` Duy Nguyen
2013-06-08 14:20 ` Felipe Contreras
2013-06-09 4:34 ` Jeff King
2013-06-09 9:58 ` Ramkumar Ramachandra
2013-06-09 17:55 ` Jeff King
2013-06-09 18:06 ` Ramkumar Ramachandra
2013-06-09 18:11 ` Felipe Contreras
2013-06-09 18:22 ` Jeff King
2013-06-09 18:29 ` Felipe Contreras
2013-06-09 18:44 ` Ramkumar Ramachandra
2013-06-09 18:49 ` Jeff King
2013-06-09 18:54 ` Felipe Contreras
2013-06-09 18:07 ` Felipe Contreras
2013-06-09 12:09 ` Felipe Contreras
2013-06-08 13:28 ` Felipe Contreras
2013-06-08 16:49 ` Jonathan Nieder
2013-06-08 17:06 ` Felipe Contreras
2013-06-08 17:34 ` Jonathan Nieder
2013-06-08 17:44 ` Felipe Contreras
2013-06-08 19:15 ` Felipe Contreras
2013-06-09 1:40 ` Jonathan Nieder
2013-06-09 2:17 ` Felipe Contreras
2013-06-09 3:21 ` Jonathan Nieder
2013-06-09 3:34 ` Felipe Contreras
2013-06-09 5:26 ` Jeff King
2013-06-09 12:15 ` Felipe Contreras
2013-06-09 17:40 ` Jeff King
2013-06-09 18:01 ` Felipe Contreras
2013-06-09 18:10 ` Jeff King
2013-06-09 18:16 ` Felipe Contreras
2013-06-09 19:11 ` Johan Herland
2013-06-09 19:29 ` Felipe Contreras
2013-06-09 21:42 ` Michael Haggerty
2013-06-09 23:40 ` Stefano Lattarini
2013-06-10 5:15 ` Felipe Contreras
2013-06-10 9:05 ` Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin) Stefano Lattarini
2013-06-10 16:58 ` Felipe Contreras
2013-06-10 18:11 ` Martin von Zweigbergk
2013-06-10 18:33 ` Martin Langhoff
2013-06-10 18:40 ` Martin von Zweigbergk
2013-06-10 21:34 ` Felipe Contreras
2013-06-10 5:12 ` [PATCH 2/2] Move sequencer to builtin Felipe Contreras
2013-06-11 9:18 ` Andres Freund
2013-06-11 9:29 ` Felipe Contreras
2013-06-20 21:11 ` Thiago Farina
2013-06-09 17:53 ` Thomas Rast
2013-06-09 18:03 ` Felipe Contreras
2013-06-09 12:48 ` Ramkumar Ramachandra
2013-06-09 13:08 ` Felipe Contreras
2013-06-09 18:04 ` Jeff King
2013-06-09 18:32 ` Ramkumar Ramachandra
2013-06-09 18:45 ` Jeff King
2013-06-09 19:57 ` Jonathan Nieder
2013-06-09 20:07 ` Felipe Contreras
2013-06-09 20:34 ` Ramkumar Ramachandra
2013-06-09 21:39 ` Junio C Hamano
2013-06-10 5:06 ` Felipe Contreras
2013-06-10 8:32 ` Junio C Hamano
2013-06-10 16:53 ` Felipe Contreras
2013-06-10 16:55 ` Felipe Contreras
2013-06-10 17:34 ` Matthieu Moy
2013-06-10 18:09 ` Ramkumar Ramachandra
2013-06-10 21:43 ` Felipe Contreras
2013-06-09 18:48 ` Felipe Contreras
2013-06-09 19:25 ` Thomas Rast
2013-06-09 19:54 ` Ramkumar Ramachandra
2013-06-09 20:02 ` Felipe Contreras
2013-06-08 3:35 ` [PATCH 0/2] Move sequencer Ramkumar Ramachandra
2013-06-08 10:26 ` 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALkWK0mw8=CMuyw5-E0fzh+c6Om_NCgHohqa_p=J_kw3UfJCJQ@mail.gmail.com' \
--to=artagnon@gmail.com \
--cc=drafnel@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=pclouds@gmail.com \
--cc=sop@google.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).