Re: git, porcelain, darcs, and version 1.0

I certainly don't think the lib interface is anywhere near stable:
Linus accepted my change to index_fd far too easily.

Noted, thanks for the info.

(This makes a lot of sense, Git is evolving very fast.  I haven't
looked at Git since mid-April, and I'm very much impressed at the
difference between 0.6 and 0.99.)

Ugh.  That's what they do in the commercial world.  We have it so much
better here in Linux & BSD land: you just add a "depends libgit1" line
to your package, and the right thing happens: minor updates happen
automatically and changes that break the interface don't.

This is, of course, only possible when there are stable interfaces,
which in turn make change problematic.  (Which, as far as I
understand, is the very reason why the Linux kernel tree contains
everyone's and his brother's driver rather than having a stable module
ABI, but that's besides the point.)

Darcs and git work together to determine the minimal amount
that needs to go into libgit1.so.

Hold on...  Nobody is speaking about *binary* compatibility, it's
source-level compatibility that we need.  There is absolutely no
reason to introduce the complexities of shared libraries into the
picture.

                                        Juliusz

quoted

Darcs and git work together to determine the minimal amount
that needs to go into libgit1.so.

Hold on...  Nobody is speaking about *binary* compatibility, it's
source-level compatibility that we need.  There is absolutely no
reason to introduce the complexities of shared libraries into the
picture.

Source level compatibility and stability is the big deal.  Compared to 
that, shared libraries are an implementation detail, in my opinion. 
Sometimes those details get "interesting", but they are soluble.

I could care less whether you use libgit.a or a libgit.so.  Just as long 
as distros or anybody else can update their darcs if a major data-loss 
bug is found in git.  A recompile is acceptable.  Dealing with the 
addition of a parameter to index_fd() is not.

Bryan