{"thread":{"id":"26806","subject":"Industrywide breakthrough innovation - Git as a key role of distribution","startedAt":"2011-03-20T21:08:54Z","lastAt":"2011-03-22T00:21:15Z","messageCount":6,"participants":["Kalle Launiala","Jonathan Nieder","Marc Weber","Randal L. Schwartz","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"163840","messageId":"AANLkTinkuSJBvftDCh8++UyV5Wc=sMRr1+vc8WbeFYMs@mail.gmail.com","threadId":"26806","inReplyTo":null,"subject":"Industrywide breakthrough innovation - Git as a key role of distribution","fromName":"Kalle Launiala","fromEmail":"kalle.launiala@gmail.com","sentAt":"2011-03-20T21:08:54Z","receivedAt":"2011-03-20T21:08:54Z","isPatch":false,"sender":{"key":"kalle.launiala@gmail.com","avatar":null},"body":"Respectful Git mailing list readers.\n\nI was encouraged to \"Ask the Git community directly\" as is writtein\nthe www.git-scm.com site.\n\n\n== Disclaimer\n\nThis is not a trolling post or suggestion of something that is not\nfinished. The technology that I'm \"lightly\" referring as industry\nbreakthrough exists. I just happened to find out that Git (alongside\nwith social coding sites such as Gitorious and GitHub) already fills\nup the repository and distribution technology that the \"abstractions\"\nrequire.\n\nPlease do not let the current platform examples fool you; our\ntechnology base was on Microsoft's stack, yet this technology is\ntotally platform agnostic. This however means that the material is\nnonexistent on Linux technology demos (although there are solid\ndemonstrations available for Microsoft's stack).\n\nI have tried to approach Linux community (through Linux Foundation,\nLDN and finally www.linux.com, but I have failed to meet any\ncentralized point to help us figure out Linux development - we know\nour technology, but we need help getting reference implementations on\nLinux common languages to be able to abstract them).\n\n== End of Disclaimer.\n\n\nNow in brief; I claim that software development can be trivialized\n(and its efficiency boosted) to absolute maximum. The technology is\nridiculously simple stack on top of existing technologies (it's\nmoreover a methodology).\n\nIt is by its very nature completely open and completely free, platform\nagnostic. Usable by anyone; learning curve is really simple\n(considering the learning includes understanding how to define the\narchitectural design and include reference implementation within it).\n\nThe thing that Git solves perfectly is described in this visualization:\nhttp://abstraction.codeplex.com/wikipage?title=Subscribing%20to%20Reference%20Abstractions&referringTitle=Documentation\n\nThe full technology case theory, key differentiators and examples\n(although light with videos) can be found:\nhttp://abstraction.codeplex.com/documentation\n\nThe absolutely trivialized software development is presented in the\ndocumentation's first link's video followed by visualization of\nmultilevel abstraction stack - I know this does not open properly\nwithout any hands-on experience on abstractions.\n\n\nI am very willing and happy to discuss how this can be applied to\nLinux (both applications and kernel) development, as it is applicable\nto anything that needs documentation and structured implementation of\nany size. This technology brings Linux in-par and way beyond of\nWindows in end-developer experience; and allows huge advantage in\nLinux because of its versatility (that no longer needs to be\nsacrificied for solid-base for developer experience).\n\n\nHowever in this post I am simply asking help to understand Git\nproperly, so that I can design the distribution mechanism (updating\nboth ways) and for example understand the way of making statistical\ncalculations (so that any individual abstraction-provider can be\nranked in terms of follow-up \"repository forks\").\n\n\n\nPlease apologize my newbieness in mailing lists and groups, as I have\njust entered the world of open-source-development.\n\n\nHappy spring from Helsinki, Finland,\n\nKalle Launiala\n"},{"id":"163907","messageId":"20110321135931.GA3367@elie","threadId":"26806","inReplyTo":"AANLkTinkuSJBvftDCh8++UyV5Wc=sMRr1+vc8WbeFYMs@mail.gmail.com","subject":"Getting started with git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-03-21T13:59:31Z","receivedAt":"2011-03-21T13:59:31Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi!\n\nKalle Launiala wrote:\n\n> [Subject: Industrywide breakthrough innovation - Git as a key role of distribution]\n[30 lines of filler]\n> == End of Disclaimer.\n\nPlease don't do that.  Most of your audience isn't going to get\npast that.\n\n> However in this post I am simply asking help to understand Git\n> properly\n\nAre you a programmer?  I'd recommend starting with\n\n http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html\n\nand moving on to\n\n http://www.kernel.org/pub/software/scm/git/docs/gittutorial-2.html\n\nand\n\n http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#hacking-git\n\nHope that helps,\nJonathan\n"},{"id":"163909","messageId":"1300716396-sup-4742@nixos","threadId":"26806","inReplyTo":"AANLkTinkuSJBvftDCh8++UyV5Wc=sMRr1+vc8WbeFYMs@mail.gmail.com","subject":"Re: Industrywide breakthrough innovation - Git as a key role of distribution","fromName":"Marc Weber","fromEmail":"marco-oweber@gmx.de","sentAt":"2011-03-21T14:12:00Z","receivedAt":"2011-03-21T14:12:00Z","isPatch":false,"sender":{"key":"marco-oweber@gmx.de","avatar":null},"body":"\nHi Kalle Launiala,\n\n> However in this post I am simply asking help to understand Git\n> properly,\n\nYou should start your mail with the most important request top (like\nnewspapers do).\nI feel that could have been tha sentence which should have been top.\n\nI wrote this mail because I saw your mail - I even clicked on your\nlinks - but it didn't make any sense to me previously.\n\nMarc Weber\n"},{"id":"163915","messageId":"864o6wiixo.fsf@red.stonehenge.com","threadId":"26806","inReplyTo":"1300716396-sup-4742@nixos","subject":"Re: Industrywide breakthrough innovation - Git as a key role of distribution","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2011-03-21T15:37:07Z","receivedAt":"2011-03-21T15:37:07Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Marc\" == Marc Weber <marco-oweber@gmx.de> writes:\n\nMarc> I wrote this mail because I saw your mail - I even clicked on your\nMarc> links - but it didn't make any sense to me previously.\n\nThis one didn't make much sense either. I had to read it three times to\neven begin to contemplate \"what action am I being asked to do?\".\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"163930","messageId":"7vd3lkqt6m.fsf@alter.siamese.dyndns.org","threadId":"26806","inReplyTo":"864o6wiixo.fsf@red.stonehenge.com","subject":"Re: Industrywide breakthrough innovation - Git as a key role of distribution","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-21T17:28:33Z","receivedAt":"2011-03-21T17:28:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Marc\" == Marc Weber <marco-oweber@gmx.de> writes:\n>\n> Marc> I wrote this mail because I saw your mail - I even clicked on your\n> Marc> links - but it didn't make any sense to me previously.\n>\n> This one didn't make much sense either. I had to read it three times to\n> even begin to contemplate \"what action am I being asked to do?\".\n\nYou read it three times?  You have too much time on your hand....\n"},{"id":"164008","messageId":"AANLkTimwR=knX4ORAWROutn=kxAhBUrUt0BgBTNA9G6A@mail.gmail.com","threadId":"26806","inReplyTo":"20110321135931.GA3367@elie","subject":"Re: Getting started with git","fromName":"Kalle Launiala","fromEmail":"kalle.launiala@gmail.com","sentAt":"2011-03-22T00:21:15Z","receivedAt":"2011-03-22T00:21:15Z","isPatch":false,"sender":{"key":"kalle.launiala@gmail.com","avatar":null},"body":"Hello!\n\nThanks for the links of overall programmer requirements, been reading\nsuch so far as well. The hacking guide was fresh compared to what I\ndiscovered.\n\nNow the reason of specific detail understanding of the Git was to use\nit on wide-range software-code-block distribution. I would like to\nknow if the following scenario either will \"blow up\" something or has\nsome other anti-Git patterns hidden inside.\n\n1. Git repositories vs. \"traditional\" branch/merge\n\nWithin the current spec, we have identified \"branching/merging\" that\nis VCS supported conflict management only feasible option. With Git\nthis seems to turn to forked/linked independent repositories; this\nseems the best option. Every independent software-block would have an\nindependent root-repository of its own.\n\nAny reason why Git would be using branching at all in distributing\nbetween-project data, even when in traditional VCS they would be\nwithin same repository?\n\n2. Scalability, when having tiny repositories that are chained to the\nend-developer\n\nBasically none of the \"bottom\" is going to push back any changes, so\nthey're effectively just readers, and also from the nearest\nrepository; the repository syncing (while likely can be automated out)\nwill go with normal pulls. I'm not worrying about \"seconds to pull\",\nbut moreover is there something architectural structure, that will\ncause single-bottleneck.\n\nIs there any scalability issue, if there are say 10 levels from root\nrepository to the end-user-bottom (in between various feature-adding\nor modifying tailoring), and total number of children of the bottom\nlevel grows to hundreds of thousands?\n\n\n3. Distribution of catalogues, registering \"Abstractions\"\n\nRegistering of new \"Abstractions\" from any provider (be it major\norganization or single consultant) would be dealt with specific\n\"distribution\" repository chain. Pushing the \"Registration Request\"\nwithin the catalogue would be fullfilled by validating the data in the\nclaimed repository. The format of the data is strongly schema based\nXML all the way. The openly used \"root\" catalogue would be synced\nglobally (daily or so, not immediatelly); the dedicated \"private\" or\nother independent catalogue providers would be in charge of their\npolicies.\n\nAre there any experience on this kind of use for Git?\n\n\n4. Handling \"private\" catalogues; repository access filtered with\nclient-access-control\n\nPrivate catalogues would be handled in a way, that their\nexistence/registration would be standard-pushed up to the chain.\nHowever all the information of their data and their content would be\ncontained only within the repository. Hence, only the clients that\nhave the access to connect to the repository could fetch the actual\ncatalogue of information. They would cache their catalogues with same\nmanner as would the root catalogue.\n\nEven if the clients would get improper private entires in their\nconnection lists, they would only get any real information out, if\ntheir credentials authorized on the target repository.\n\nAny blockers that come in mind with this?\n\n\nKalle\n"}]}