> Not until all the data structures are really really stable.
Fine by me to wait, though perhaps not for the same reason, and perhaps
not as long.
A libgit.so can deal with data structure changes just as well as a set
of command line utilities. So long as everything funnels through one
place, yo
On Sun, 17 Apr 2005, Paul Jackson wrote:
>
> I'd encourage you to invite someone to provide a libgit.
Not until all the data structures are really really stable.
That's the thing - we can keep the _program_ interfaces somewhat stable.
But internally we may change stuff wildly, and anybody who
Linus wrote:
> But then I'd really suggest that you use "git" itself, not any
> "libgit". Ie you take _all_ the plumbing as real programs, and instead of
> trying to link against individual routines, you'd _script_ it.
I think you've got this upside down, Linus.
Trying to make the executable 'git
Junio wrote:
> What Linus is saying is that he wants you to talk with git
> plumbing by invoking the executables he have, via system(3),
> popen(3), etc.
Hopefully, Linus didn't specify system(3) or popen(3) for production
software.
They are a rich source of security holes. Inefficient, too, sin
> "NA" == Nomad Arton <[EMAIL PROTECTED]> writes:
NA> Linus Torvalds schrieb:
>> In fact, one of my hopes was that other SCM's could just use the git
>> plumbing. But then I'd really suggest that you use "git" itself, not any
>> "libgit". Ie you take _all_ the plumbing as real programs, and in
Linus Torvalds schrieb:
In fact, one of my hopes was that other SCM's could just use the git
plumbing. But then I'd really suggest that you use "git" itself, not any
"libgit". Ie you take _all_ the plumbing as real programs, and instead of
trying to link against individual routines, you'd _script_
Linus Torvalds wrote:
On Sun, 17 Apr 2005, David Roundy wrote:
That's all right. Darcs would only access the cached data through a
git-caching layer, and we've already got an abstraction layer over the
pristine cache. As long as the git layer can quickly retrieve the contents
of a given file, we
On Sun, 17 Apr 2005, David Roundy wrote:
>
> That's all right. Darcs would only access the cached data through a
> git-caching layer, and we've already got an abstraction layer over the
> pristine cache. As long as the git layer can quickly retrieve the contents
> of a given file, we should be
On Sat, Apr 16, 2005 at 03:43:02PM -0700, Linus Torvalds wrote:
> On Sat, 16 Apr 2005, David Roundy wrote:
> > 1) Would this actually be a good idea? It seems good to me, but there may
> > be other considerations that I haven't thought of.
>
> I really don't know how well the git index file will w
On Sat, 16 Apr 2005, David Roundy wrote:
>
> I've been thinking about the possibility of using the git "current
> directory cache" code in darcs.
Go wild. The license is GPLv2, with the limitation that I really do want
to see v3 before I re-license anything at all, so if you take it into
darcs,
* David Roundy <[EMAIL PROTECTED]> wrote:
> 2) Will a license be chosen soon for git? Or has one been chosen, and
> I missed it? I can't really include git code in darcs without a
> license. I'd prefer GPLv2 or later (since that's how darcs is
> licensed), but as long as it's at least compabi
Hello Linus and various git developers (ccing darcs developers),
I've been thinking about the possibility of using the git "current
directory cache" code in darcs. Darcs already has an abstraction layer
over its pristine directory cache, so this shouldn't be too hard--provided
the git code is und
12 matches
Mail list logo
