{"thread":{"id":"44024","subject":"Git Miniconference at Plumbers","startedAt":"2016-09-06T18:02:25Z","lastAt":"2016-09-14T17:26:50Z","messageCount":10,"participants":["Jon Loeliger","Jeff King","David Bainbridge","Junio C Hamano","Jakub Narębski","Lars Schneider","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"301215","messageId":"E1bhKNo-0005m2-5z@mylo.jdl.com","threadId":"44024","inReplyTo":null,"subject":"Git Miniconference at Plumbers","fromName":"Jon Loeliger","fromEmail":"jdl@jdl.com","sentAt":"2016-09-06T17:42:04Z","receivedAt":"2016-09-06T18:02:25Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"\nFolks,\n\nI have recently been enlisted by folks at the Linux Foundation to\nhelp run a Miniconference on Git at the Plumbers Conference [*]\nthis fall.\n\nWe currently have both Junio Hamano and Josh Triplett signed\nup to do talks. Hopefully, though not confirmed yet, Junio\nwill give us a brief \"State of the Git Union\" to set the stage\nfor a few more presentations and some discussion about the\nFuture of Git. Josh has volunteered to talk about a patch\nseries manager he's been developing.\n\nRumor also suggests that the Man In The\tBowtie might make\nan appearance as well.\tWith luck, Mr. Bottomley might\noffer a\tspeaking role as well!\tWe'll see.\n\nI would like to solicit one or two more solid talks from\nthe community, either the Linux Kernel community or the\nGit community proper. If you are so interested, please\nsend me some mail.\n\nThanks,\njdl\n\n\n[*] -- http://www.linuxplumbersconf.org/2016/\n"},{"id":"301683","messageId":"20160912004233.qh6uf35v5ylrboz6@sigill.intra.peff.net","threadId":"44024","inReplyTo":"E1bhKNo-0005m2-5z@mylo.jdl.com","subject":"Re: Git Miniconference at Plumbers","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-09-12T00:42:33Z","receivedAt":"2016-09-12T00:42:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 06, 2016 at 12:42:04PM -0500, Jon Loeliger wrote:\n\n> I have recently been enlisted by folks at the Linux Foundation to\n> help run a Miniconference on Git at the Plumbers Conference [*]\n> this fall.\n\nI see the conference runs for 4 days; I assume the Git portion will just\nbe one day. Do you know yet which day?\n\n-Peff\n"},{"id":"301721","messageId":"E1bjRLd-0005k0-Vb@mylo.jdl.com","threadId":"44024","inReplyTo":"20160912004233.qh6uf35v5ylrboz6@sigill.intra.peff.net","subject":"Re: Git Miniconference at Plumbers","fromName":"Jon Loeliger","fromEmail":"jdl@jdl.com","sentAt":"2016-09-12T13:32:33Z","receivedAt":"2016-09-12T13:32:42Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"So, like, Jeff King said:\n> On Tue, Sep 06, 2016 at 12:42:04PM -0500, Jon Loeliger wrote:\n> \n> > I have recently been enlisted by folks at the Linux Foundation to\n> > help run a Miniconference on Git at the Plumbers Conference [*]\n> > this fall.\n> \n> I see the conference runs for 4 days; I assume the Git portion will just\n> be one day.\n\nYes, and yes. Likely even \"a half day\".\n\n> Do you know yet which day?\n\nNo. Sorry.\n\n> -Peff\n\njdl\n"},{"id":"301736","messageId":"E1bjVfp-0006sG-89@mylo.jdl.com","threadId":"44024","inReplyTo":"DB5PR07MB1448B5EDFE2E2D84C42A8AFCE2FF0@DB5PR07MB1448.eurprd07.prod.outlook.com","subject":"Re: Git Miniconference at Plumbers","fromName":"Jon Loeliger","fromEmail":"jdl@jdl.com","sentAt":"2016-09-12T18:09:41Z","receivedAt":"2016-09-12T18:09:49Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"So, like, David Bainbridge said:\n> Hi,\n> \n> The subject matter of the conference looks really interesting but I am\n> unlikely to be able to attend, unfortunately.\n> \n> The subjects being covered like the current State of Git and the\n> Future of Git, for example, deserve much wider exposure, and I would\n> certainly appreciate hearing the thoughts of Junio and others.\n\nIndeed.\n\n> Does anyone know whether the sessions will be recorded in any way?\n\nI am uncertain about outright recording (digital video/audio),\nbut there will be at least summarizing notes taken and posted.\nAnyone wishing to record the talks/discussions is likely welcome\nto do so.\n\nHTH,\njdl\n"},{"id":"301737","messageId":"DB5PR07MB1448B5EDFE2E2D84C42A8AFCE2FF0@DB5PR07MB1448.eurprd07.prod.outlook.com","threadId":"44024","inReplyTo":"E1bjRLd-0005k0-Vb@mylo.jdl.com","subject":"RE: Git Miniconference at Plumbers","fromName":"David Bainbridge","fromEmail":"david.bainbridge@ericsson.com","sentAt":"2016-09-12T17:53:33Z","receivedAt":"2016-09-12T18:11:41Z","isPatch":false,"sender":{"key":"david.bainbridge@ericsson.com","avatar":null},"body":"Hi,\n\nThe subject matter of the conference looks really interesting but I am unlikely to be able to attend, unfortunately.\n\nThe subjects being covered like the current State of Git and the Future of Git, for example, deserve much wider exposure, and I would certainly appreciate hearing the thoughts of Junio and others.\n\nDoes anyone know whether the sessions will be recorded in any way?\n\nThanks\n\nDavid\n\nDAVID BAINBRIDGE\nProduct Manager SW Development\n\nEricsson\n8500 Decarie\nMontreal, H4P 2N2, Canada\ndavid.bainbridge@ericsson.com\nwww.ericsson.com\n\n-----Original Message-----\nFrom: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Jon Loeliger\nSent: Monday, September 12, 2016 09:33\nTo: Jeff King \nCc: git@vger.kernel.org\nSubject: Re: Git Miniconference at Plumbers\n\nSo, like, Jeff King said:\n> On Tue, Sep 06, 2016 at 12:42:04PM -0500, Jon Loeliger wrote:\n> \n> > I have recently been enlisted by folks at the Linux Foundation to \n> > help run a Miniconference on Git at the Plumbers Conference [*] this \n> > fall.\n> \n> I see the conference runs for 4 days; I assume the Git portion will \n> just be one day.\n\nYes, and yes. Likely even \"a half day\".\n\n> Do you know yet which day?\n\nNo. Sorry.\n\n> -Peff\n\njdl\n"},{"id":"301757","messageId":"xmqqeg4o27zw.fsf@gitster.mtv.corp.google.com","threadId":"44024","inReplyTo":"E1bjVfp-0006sG-89@mylo.jdl.com","subject":"Re: Git Miniconference at Plumbers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-12T20:11:47Z","receivedAt":"2016-09-12T20:12:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger writes:\n\n> So, like, David Bainbridge said:\n>> Hi,\n>> \n>> The subject matter of the conference looks really interesting but I am\n>> unlikely to be able to attend, unfortunately.\n>> \n>> The subjects being covered like the current State of Git and the\n>> Future of Git, for example, deserve much wider exposure, and I would\n>> certainly appreciate hearing the thoughts of Junio and others.\n>\n> Indeed.\n\nYou do not need to go to NM to _hear_ that. Basically, I want us\nnot to have \"big\" plans that come from the top.\n\nNow, you heard it ;-)\n\nThere are areas that we as Git community would want to address for\nsome audience that were discovered over the years, and that \"some\naudience\" might even be a large population of Git users, but if that\ndoes not have overlap with Kernel Plumbers, the Plumbers mini-conf\nmay not be a suitable venue for even mentioning them. E.g. the\nenhancement of the submodule subsystem to allow more end-user facing\ncommands to recurse into them; rearchitecting the index and redoing\nthe \"sparse checkout\" hack so that we can do narrow clones more\nproperly; supporting \"huge objects\" better in the object layer,\nwithout having to resort to ugly hacks like GitLFS that will never\nbe part of the core Git. These things may all be worth talking\nabout in wider Git setting, but some of them may be waste of time to\nbring up in the Plumbers' venue.\n\nThe future of Git is shaped largely by end-user itches. From my\npoint of view, Git people are going there primarily to find what\nKernel Plubmbers' itches are, and help assessing the workflow\nimprovements around Git the Plumbers are wishing for or designing\nthemselves by being there, because we are at the best position to\ntell what kind of enhancement to Git is feasible and what is\nunlikely to happen in the near term.\n"},{"id":"301768","messageId":"bf2edfe8-667c-8a98-64f1-510983abf9f9@gmail.com","threadId":"44024","inReplyTo":"E1bjVfp-0006sG-89@mylo.jdl.com","subject":"Re: Git Miniconference at Plumbers","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-09-12T21:23:27Z","receivedAt":"2016-09-12T21:23:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 12.09.2016 o 20:09, Jon Loeliger napisał:\n> So, like, David Bainbridge said:\n\n>> Does anyone know whether the sessions will be recorded in any way?\n> \n> I am uncertain about outright recording (digital video/audio),\n> but there will be at least summarizing notes taken and posted.\n> Anyone wishing to record the talks/discussions is likely welcome\n> to do so.\n\nI think LWN.net usually covers Linux Plumbers Conference, see e.g.\nhttps://lwn.net/Archives/ConferenceByYear/#2015-Linux_Plumbers_Conference\n\nHopefully they would cover it this year too.\n\nHTH\n-- \nJakub Narębski\n\n"},{"id":"301780","messageId":"1019E7FD-0AC0-4BCE-B810-BE20968DFEE9@gmail.com","threadId":"44024","inReplyTo":"xmqqeg4o27zw.fsf@gitster.mtv.corp.google.com","subject":"Re: Git Miniconference at Plumbers","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-09-12T23:14:12Z","receivedAt":"2016-09-12T23:14:21Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 12 Sep 2016, at 21:11, Junio C Hamano wrote:\n> \n> [..]\n> properly; supporting \"huge objects\" better in the object layer,\n> without having to resort to ugly hacks like GitLFS that will never\n> be part of the core Git. [...]\n\nI agree with you that GitLFS is an ugly hack.\n\nSome applications have test data, image assets, and other data sets that\nneed to be versioned along with the source code.\n\nHow would you deal with these kind of \"huge objects\" _today_?\n\nThanks,\nLars\n"},{"id":"301912","messageId":"CAP8UFD0M8MDs-0UAFgx288XVdWg_XP=bOwAWoXdY=5Sg7pMFsw@mail.gmail.com","threadId":"44024","inReplyTo":"1019E7FD-0AC0-4BCE-B810-BE20968DFEE9@gmail.com","subject":"Re: Git Miniconference at Plumbers","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-09-14T16:27:32Z","receivedAt":"2016-09-14T16:27:39Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Sep 13, 2016 at 1:14 AM, Lars Schneider\n wrote:\n>\n>> On 12 Sep 2016, at 21:11, Junio C Hamano wrote:\n>>\n>> [..]\n>> properly; supporting \"huge objects\" better in the object layer,\n>> without having to resort to ugly hacks like GitLFS that will never\n>> be part of the core Git. [...]\n>\n> I agree with you that GitLFS is an ugly hack.\n>\n> Some applications have test data, image assets, and other data sets that\n> need to be versioned along with the source code.\n>\n> How would you deal with these kind of \"huge objects\" _today_?\n\nI think that Junio was saying that this problem and other problems\nlike this one are indeed itches for some people, but maybe not for\nkernel community.\n\nAbout this specific problem, as you probably know, I started working\non adding support for external object databases, on top of some\nprevious work that Peff had started some years ago:\n\nhttps://public-inbox.org/git/20160628181933.24620-1-chriscool@tuxfamily.org/\n\nSo if you want to better deal with huge objects in the near future,\nyou are welcome to help on this.\n"},{"id":"301913","messageId":"xmqqsht2qtnz.fsf@gitster.mtv.corp.google.com","threadId":"44024","inReplyTo":"1019E7FD-0AC0-4BCE-B810-BE20968DFEE9@gmail.com","subject":"Re: Git Miniconference at Plumbers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-14T17:26:40Z","receivedAt":"2016-09-14T17:26:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider writes:\n\n> Some applications have test data, image assets, and other data sets that\n> need to be versioned along with the source code.\n>\n> How would you deal with these kind of \"huge objects\" _today_?\n\nWhen you know that you'd find the answer to that question totally\nuninteresting, why do you even bother to ask? ;-)\n\nI don't, and if I had to, I would deal with them just like any other\nobjects.\n\nA more interesting pair of questions to ask would be what the\nfundamental requirement for an acceptable solution is, and what\nsolution within the constraint I would envision, if I were given a\ngroup competent Git hackers and enough time to realize it.\n\nThe most important constraint is that any acceptable solution should\npreserve the object identity.\n\nAnd starting from a \"I don't but if I had to...\" repository that is\ncreated in a dumb way, a solution that satisifies the constraint may\nwork like this, requiring enhancements to various parts of the\nsystem:\n\n - The \"upload-pack\" protocol would allow the owner of a such\n repository and the party that \"git clone\"'s from there to\n negotiate:\n\n . what it means for a object to be \"huge\" (e.g. the owner may\n implicitly show the preference by marking a packfile as\n containing such \"huge\" objects, may configure that blobs that\n appear at paths that match certain glob pattern are \"huge\", or\n the sender and the receiver may say objects that are larger\n than X MB are \"huge\", etc.); and\n\n . what to do with \"huge\" objects (e.g. the receiver may ask for\n a full clone, or the receiver may ask to omit \"huge\" ones from\n the initial transfer)\n\n - The \"upload-pack\" protocol would give, in addition to the normal\n pack stream that conveys only non-\"huge\" objects, for each of\n \"huge\" objects that are not transferred, what its object name is\n and how it can later be retrieved.\n\n - Just like packing objects in packfiles was added as a different\n implementation to store objects in the object database that is\n better than storing them individually as loose object files,\n there will be a third way to store such \"huge\" object _in_ the\n object database, which may actually not _store_ them locally at\n all. The local object store may merely have placeholders for\n them, in which instructions for how it can be acquired when\n necessary are stored. The extra information sent over the\n \"upload-pack\" protocol for \"huge\" objects with the previous\n bullet-point are used to store these objects in this \"third\" way.\n\n - A new mechanism would allow such objects that are stored in this\n \"third\" way to be retrieved lazily or on-demand.\n\nThere are other enhancements whose necessity will fall naturally out\nof such a lazy scheme outlined above. E.g. \"fsck\" needs to learn\nthat the objects stored in the third way are considered to \"exist\"\nbut their actual contents is not expected to be verifiable until\nthey are retrieved. \"send-pack\" (i.e. running \"git push\" from a\nrepository cloned with the procedure outlined above) needs to treat\nthe objects stored in the third way differently (most likely, it\nwill fail a request for full-clone and send \"not here, but you can\nget it this way\" for them). Local operations that need more than\nobject names need to learn reasonable fallback behaviours to work\nwhen the actual object contents are not yet available (e.g. all of\nthem may offer \"this is not yet available; do you want to get\non-demand?\" or there may even be \"object.ondemand\" configuration\noption to skip the end-user interaction. When on-demand retrieving\nis not done, \"git archive\" may place a placeholder file in its\noutput that says \"no data (yet) here\", \"git log --raw\" may show the\nobject name but \"git log -p\" may say \"insufficient data to produce a\npatch\", etc.) [*1*].\n\nBecause we start from the \"object identity should not change\", you\ndo not have to make a decision upfront when preparing the ultimate\nsource of the truth. When you take a clone-network of a single\nproject as a whole, somebody needs to hold the entire set of objects\nsomewhere, and many of the repository in the clone-network may have\n\"huge\" objects in the third \"not here yet, here is how to get it\"\nform. As the system improves, and as the networking and storage\ntechnology changes, the definition of \"huge\" WILL change over time\nand those repositories can turn the ones that used to be \"huge\" into\nnormal objects.\n\nIf you use approaches taken by various clean/smudge based current\ncrop of solutions [*2*], on the other hand, once you decide a blob\nobject is \"huge\" and needs to be replaced with a surrogate (to be\ninstantiated via the \"clean\" filter), the \"huge\" object _has_ to\nstay in the surrogate form in the containing tree and you cannot\nchange the division between \"huge\" and \"normal\" ever without\nrewriting the history.\n\n\n[Footnote]\n\n*1* Astute readers would realize that the utility of such a \"third\n way\" object storage mechanism is not limited to \"keep and\n transfer huge objects lazily\". The same mechanism can say \"not\n yet here, and there is no way for _you_ to retrieve the\n contents\", which is an effective way to \"obliterate\" an object.\n\n*2* I called them \"hacks\" because they are practical compromise that\n can be done with today's Git, while sidestepping harder problems\n that are needed to be solved to realize the solution outlined\n above.\n"}]}