{"thread":{"id":"1263","subject":"Darcs-Git: upgrading to Git 0.99","startedAt":"2005-07-16T20:45:47Z","lastAt":"2005-07-18T20:28:26Z","messageCount":7,"participants":["Juliusz Chroboczek","David Roundy","Bryan Larsen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6198","messageId":"7islyev5s4.fsf@lanthane.pps.jussieu.fr","threadId":"1263","inReplyTo":null,"subject":"Darcs-Git: upgrading to Git 0.99","fromName":"Juliusz Chroboczek","fromEmail":"juliusz.chroboczek@pps.jussieu.fr","sentAt":"2005-07-16T20:45:47Z","receivedAt":"2005-07-16T20:45:47Z","isPatch":false,"sender":{"key":"juliusz.chroboczek@pps.jussieu.fr","avatar":null},"body":"[CC'd to the Git mailling list; please CC any replies to Darcs-Devel]\n\nDavid, Ian,\n\nI'd like to upgrade the Git code used in Darcs to 0.99 (we're\ncurrently using 0.6).  There are two good reasons for that, the first\nof which is actually a showstopper:\n\n - the format of Git repositories has changed incompatibly, with a new\n   kind of thing called the ``pack'' (a very neat performance hack, by\n   the way); hence, Darcs-Git is unable to read recent Git repos,\n   unless you use the Git tools to unpack them;\n\n - 0.99 actually exports usable interfaces, which will allow us to use\n   pristine Git sources in Darcs.\n\nNow I'm wondering how to do that.  Currently, I'm using a nasty hack\nusing the C preprocessor to include just the sources we need in\nDarcs.  As 0.99 builds a ``libgit.a'', I'd like to use that instead.\n\nThere are three ways to do that:\n\n  (1) require that the users put a suitable libgit.a in /usr/local/lib\n      before building Darcs, and distribute a tarball of Git from\n      darcs.net;\n\n  (2) include just the sources needed for libgit.a in Darcs, and have\n      the Darcs build build a local libgit\n\n  (3) as (2), but include all of Git, including their\n      ``user-friendly'' scripts.\n\nSolution (2) will include 33 files totalling 167KB, while (3) is about\na megabyte of source.\n\nMy personal favourite is solution (2), as it is simple for both the\nusers and us.  I'm not very keen on (1), as it will cause problems\nwhen the friendly Git folks change their interfaces, but have no\nstrong dislike towards it if it's what you think is right.  (3) is\ndefinitely overkill.\n\n                                        Juliusz\n"},{"id":"6218","messageId":"20050717104035.GA8315@abridgegame.org","threadId":"1263","inReplyTo":"7islyev5s4.fsf@lanthane.pps.jussieu.fr","subject":"Re: [darcs-devel] Darcs-Git: upgrading to Git 0.99","fromName":"David Roundy","fromEmail":"droundy@abridgegame.org","sentAt":"2005-07-17T10:40:42Z","receivedAt":"2005-07-17T10:40:42Z","isPatch":false,"sender":{"key":"droundy@abridgegame.org","avatar":"https://gravatar.com/avatar/e8bcfd76f63303732bdfcdba6fc8ac6ccdff8f5a224a25ffaca24bd8a4c4571f?d=mp&s=160"},"body":"On Sat, Jul 16, 2005 at 10:45:47PM +0200, Juliusz Chroboczek wrote:\n> \n> I'd like to upgrade the Git code used in Darcs to 0.99 (we're\n> currently using 0.6). [...]\n\nGreat!\n\n> Now I'm wondering how to do that.  Currently, I'm using a nasty hack\n> using the C preprocessor to include just the sources we need in\n> Darcs.  As 0.99 builds a ``libgit.a'', I'd like to use that instead.\n> \n> There are three ways to do that:\n> \n>   (1) require that the users put a suitable libgit.a in /usr/local/lib\n>       before building Darcs, and distribute a tarball of Git from\n>       darcs.net;\n> \n>   (2) include just the sources needed for libgit.a in Darcs, and have\n>       the Darcs build build a local libgit\n> \n>   (3) as (2), but include all of Git, including their\n>       ``user-friendly'' scripts.\n> \n> Solution (2) will include 33 files totalling 167KB, while (3) is about\n> a megabyte of source.\n\nI'd really prefer option (1), *if* the git folks can confirm that the API\nis at least intended to be stable.  As an subtly different option, we could\ninclude a script that would download and untar the git sources and then\nbuild them.  But it'd be great to allow users to upgrade their libgit\nwithout our intervention if a protocol or repository format change occurs\nthat doesn't affect the API.\n\nI guess the real question is whether the API is more or less stable than\nthe protocols and disk formats.  If the API is more stable, we'd rather\nlink with an external libgit and be robust with respect to on-disk format\nchanges (such as pack files).  If the on-disk format is more stable, we'd\nrather include a copy of the source code and be robust with respect to API\nchanges of libgit.\n\nA fourth option would be to include git sources, but also include a\nconfigure flag that could be used to link with an external libgit.  This is\nprobably the most robust solution, but also the most complex solution (and\nthus probably not the best).\n-- \nDavid Roundy\nhttp://www.darcs.net\n"},{"id":"6239","messageId":"42DB341D.6050506@gmail.com","threadId":"1263","inReplyTo":"7islyev5s4.fsf@lanthane.pps.jussieu.fr","subject":"git, porcelain, darcs, and version 1.0","fromName":"Bryan Larsen","fromEmail":"bryan.larsen@gmail.com","sentAt":"2005-07-18T04:46:21Z","receivedAt":"2005-07-18T04:46:21Z","isPatch":false,"sender":{"key":"bryan@larsen.st","avatar":"https://avatars.githubusercontent.com/u/32073?v=4"},"body":"Juliusz Chroboczek wrote:\n> There are three ways to do that:\n> \n>   (1) require that the users put a suitable libgit.a in /usr/local/lib\n>       before building Darcs, and distribute a tarball of Git from\n>       darcs.net;\n\nI was under the impression that the stablest interface to git was the \ncommand line; we use spawnvp in stacked git.  I've been using it with \nrepositories that make the Linux kernel look small.\n\nI certainly don't think the lib interface is anywhere near stable: \nLinus accepted my change to index_fd far too easily.\n\n >\n >   (2) include just the sources needed for libgit.a in Darcs, and have\n >       the Darcs build build a local libgit\n >\n >   (3) as (2), but include all of Git, including their\n >       ``user-friendly'' scripts.\n\nUgh.  That's what they do in the commercial world.  We have it so much \nbetter here in Linux & BSD land: you just add a \"depends libgit1\" line \nto your package, and the right thing happens: minor updates happen \nautomatically and changes that break the interface don't.  Of course, \nkeeping it that easy for the user requires active effort from us, the \ndevelopers, and sometimes the pain spills over, but the benefits are nice.\n\nI see too major long-term alternatives:\n\n1) talk the darcs guys into using spawnvp\n2) talk the git people into exporting a stable lib interface\n\nIt's my opinion that #1 is a non-starter.  We want others to interact \nwith us.  I'm going to use spawnvp for my porcelain, but we should be \ninclusive.\n\nThe current 'libgit' probably contains more than Linus and Junio are \ncomfortable locking down as a stable interface, but I'm sure that \nthere's a subset that they'd be comfortable with once a relative amount \nof stability is achieved, or it may be achievable via some other method.\n\nI propose that Darcs includes all of git for now.  (I prefer this over \npartial inclusion; anybody should be able to take the darcs sources and \neasily drop in a later git).  However, the long term goal is for a \nlibrary.  Darcs and git work together to determine the minimal amount \nthat needs to go into libgit1.so.  It gets blessed by being documented, \nand doesn't change until libgit2.so.\n\nI'd like to see this added to Junio's list of \"1.0\" goals.\n\nA similar 1.0 goal would be to document porcelain's use of the .git \ndirectory.  For instance, stacked git uses .git/patches, \n.git/patchdescr.tmpl and .git/patchexport.tmpl.  If Linus does not \naccept a patch documenting this usage, stacked git should use .stgit \ninstead.\n\nBryan\n"},{"id":"6254","messageId":"7vslycnd42.fsf@assigned-by-dhcp.cox.net","threadId":"1263","inReplyTo":"42DB341D.6050506@gmail.com","subject":"Re: git, porcelain, darcs, and version 1.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-18T19:11:25Z","receivedAt":"2005-07-18T19:11:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bryan Larsen <bryan.larsen@gmail.com> writes:\n\n> ... Darcs and git work together to determine the minimal amount\n> that needs to go into libgit1.so.  It gets blessed by being\n> documented, and doesn't change until libgit2.so.\n>\n> I'd like to see this added to Junio's list of \"1.0\" goals.\n\nI should mention that I liked the libification work Brad Roberts\ndid around late April.  Unfortunately the things have been\nalways in great flux for the last couple of months, and it was\ntoo hard to include that and maintain it back then.\n\nI fully agree that supporting C-level linkage is worthy, and\nshould be one of our longer term goals.\n\n> A similar 1.0 goal would be to document porcelain's use of the .git\n> directory.  For instance, stacked git uses .git/patches,\n> .git/patchdescr.tmpl and .git/patchexport.tmpl.  If Linus does not\n> accept a patch documenting this usage, stacked git should use .stgit\n> instead.\n\nI agree that coordinating the namespace under $GIT_DIR among\nPorcelains is something we need (it was what prompted me to\nsteal the branches/ convention from Cogito).  The job of the\ncore should be to help Porcelains avoid stepping on each other's\ntoes.\n\nThe documentation of the internals for $GIT_DIR/patches is\nprobably better left to StGIT documentation, though, at the\nmoment.  When other Porcelains start wishing to access the\n\"series of patches expressed as a set of commit chain\" expressed\nby StGIT there (e.g. show patch series in addition to regular\ncommit chain in gitk), the core should help the Porcelains to\nwork well with each other, to do things in a compatible way.\nThis may involve moving some common things to core side and\nmention the convention for Porcelains to work well together in\nthe core documentation.\n\nHowever, I am slightly negative about suggesting these two to be\npart of the 1.0 goals.  Linus wanted to make 1.0 how many weeks\nago?  I personally think that a usable baseline, stable enough\nto allow stripping out the core part currently shipped as part\nof Cogito, would be a good place to stop and declare 1.0.  My\nlist was meant to enumuerate what might be missing from the\n\"usable baseline\".\n"},{"id":"6255","messageId":"7id5pfx5ci.fsf@lanthane.pps.jussieu.fr","threadId":"1263","inReplyTo":"42DB341D.6050506@gmail.com","subject":"Re: git, porcelain, darcs, and version 1.0","fromName":"Juliusz Chroboczek","fromEmail":"juliusz.chroboczek@pps.jussieu.fr","sentAt":"2005-07-18T19:49:01Z","receivedAt":"2005-07-18T19:49:01Z","isPatch":false,"sender":{"key":"juliusz.chroboczek@pps.jussieu.fr","avatar":null},"body":"> I certainly don't think the lib interface is anywhere near stable:\n> Linus accepted my change to index_fd far too easily.\n\nNoted, thanks for the info.\n\n(This makes a lot of sense, Git is evolving very fast.  I haven't\nlooked at Git since mid-April, and I'm very much impressed at the\ndifference between 0.6 and 0.99.)\n\n> Ugh.  That's what they do in the commercial world.  We have it so much\n> better here in Linux & BSD land: you just add a \"depends libgit1\" line\n> to your package, and the right thing happens: minor updates happen\n> automatically and changes that break the interface don't.\n\nThis is, of course, only possible when there are stable interfaces,\nwhich in turn make change problematic.  (Which, as far as I\nunderstand, is the very reason why the Linux kernel tree contains\neveryone's and his brother's driver rather than having a stable module\nABI, but that's besides the point.)\n\n> Darcs and git work together to determine the minimal amount\n> that needs to go into libgit1.so.\n\nHold on...  Nobody is speaking about *binary* compatibility, it's\nsource-level compatibility that we need.  There is absolutely no\nreason to introduce the complexities of shared libraries into the\npicture.\n\n                                        Juliusz\n"},{"id":"6256","messageId":"42DC0EAE.8000600@gmail.com","threadId":"1263","inReplyTo":"7vslycnd42.fsf@assigned-by-dhcp.cox.net","subject":"Re: git, porcelain, darcs, and version 1.0","fromName":"Bryan Larsen","fromEmail":"bryan.larsen@gmail.com","sentAt":"2005-07-18T20:18:54Z","receivedAt":"2005-07-18T20:18:54Z","isPatch":false,"sender":{"key":"bryan@larsen.st","avatar":"https://avatars.githubusercontent.com/u/32073?v=4"},"body":"Junio C Hamano wrote:\n> \n> I fully agree that supporting C-level linkage is worthy, and\n> should be one of our longer term goals.\n\nExcellent.\n> \n> \n>>A similar 1.0 goal would be to document porcelain's use of the .git\n>>directory.  For instance, stacked git uses .git/patches,\n>>.git/patchdescr.tmpl and .git/patchexport.tmpl.  If Linus does not\n>>accept a patch documenting this usage, stacked git should use .stgit\n>>instead.\n> \n> \n> I agree that coordinating the namespace under $GIT_DIR among\n> Porcelains is something we need (it was what prompted me to\n> steal the branches/ convention from Cogito).  The job of the\n> core should be to help Porcelains avoid stepping on each other's\n> toes.\n> \n> The documentation of the internals for $GIT_DIR/patches is\n> probably better left to StGIT documentation, though, at the\n> moment.  When other Porcelains start wishing to access the\n> \"series of patches expressed as a set of commit chain\" expressed\n> by StGIT there (e.g. show patch series in addition to regular\n> commit chain in gitk), the core should help the Porcelains to\n> work well with each other, to do things in a compatible way.\n> This may involve moving some common things to core side and\n> mention the convention for Porcelains to work well together in\n> the core documentation.\n\nI think we want the same thing, you're just expressing it explicitly: \nstgit's usage of the .git namespace should be mentioned in git \ndocumentation.  actual details belong in stgit, either explicitly in \ndocumentation or implicitly in the code.\n\n\n> \n> However, I am slightly negative about suggesting these two to be\n> part of the 1.0 goals.  Linus wanted to make 1.0 how many weeks\n> ago?  I personally think that a usable baseline, stable enough\n> to allow stripping out the core part currently shipped as part\n> of Cogito, would be a good place to stop and declare 1.0.  My\n> list was meant to enumuerate what might be missing from the\n> \"usable baseline\".\n\nAll I'm looking for is a statement like \"once we're at 1.0, darcs \ndoesn't break until 2.0\".  If we don't actually break out a blessed lib \ninterface until 1.1,  that's fine with me.  To me, 1.0 implies core \nstability.\n\nthanks,\nBryan\n"},{"id":"6257","messageId":"42DC10EA.4050502@gmail.com","threadId":"1263","inReplyTo":"7id5pfx5ci.fsf@lanthane.pps.jussieu.fr","subject":"Re: git, porcelain, darcs, and version 1.0","fromName":"Bryan Larsen","fromEmail":"bryan.larsen@gmail.com","sentAt":"2005-07-18T20:28:26Z","receivedAt":"2005-07-18T20:28:26Z","isPatch":false,"sender":{"key":"bryan@larsen.st","avatar":"https://avatars.githubusercontent.com/u/32073?v=4"},"body":"\n>>Darcs and git work together to determine the minimal amount\n>>that needs to go into libgit1.so.\n> \n> \n> Hold on...  Nobody is speaking about *binary* compatibility, it's\n> source-level compatibility that we need.  There is absolutely no\n> reason to introduce the complexities of shared libraries into the\n> picture.\n> \n\nSource level compatibility and stability is the big deal.  Compared to \nthat, shared libraries are an implementation detail, in my opinion. \nSometimes those details get \"interesting\", but they are soluble.\n\nI could care less whether you use libgit.a or a libgit.so.  Just as long \nas distros or anybody else can update their darcs if a major data-loss \nbug is found in git.  A recompile is acceptable.  Dealing with the \naddition of a parameter to index_fd() is not.\n\nBryan\n"}]}