{"thread":{"id":"38674","subject":"Fwd: An interesting opinion on DVCS/git","startedAt":"2015-03-02T03:29:30Z","lastAt":"2015-03-09T14:31:27Z","messageCount":8,"participants":["Stefan Beller","Shawn Pearce","Junio C Hamano","Randall S. Becker","David Lang","Michael J Gruber","Sitaram Chamarty","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"256820","messageId":"CAGZ79kZ8CrjwVh3+OHSV1tv+fRXaDZ_diOO5E7QnSLZ=HTFSfg@mail.gmail.com","threadId":"38674","inReplyTo":"54F2CD12.8050609@gmail.com","subject":"Fwd: An interesting opinion on DVCS/git","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-03-02T03:29:30Z","receivedAt":"2015-03-02T03:29:30Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity\n"},{"id":"256942","messageId":"CAJo=hJuKL3akaG3Xh8mH5iij_dAdMkBW8fQgvreOsUHV517gpw@mail.gmail.com","threadId":"38674","inReplyTo":"CAGZ79kZ8CrjwVh3+OHSV1tv+fRXaDZ_diOO5E7QnSLZ=HTFSfg@mail.gmail.com","subject":"Re: An interesting opinion on DVCS/git","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2015-03-03T22:49:43Z","receivedAt":"2015-03-03T22:49:43Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@google.com> wrote:\n> bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity\n\nIndeed, a DVCS like Git or Hg does not fit everyone. And neither do\ncentralized systems like Subversion. Choice is good.\n\nHowever... I found some passages troubling for Git, e.g.:\n\n---snip---\nGit is so amazingly simple to use that APress, a single publisher,\nneeds to have three different books on how to use it. It’s so simple\nthat Atlassian and GitHub both felt a need to write their own online\ntutorials to try to clarify the main Git tutorial on the actual Git\nwebsite. It’s so transparent that developers routinely tell me that\nthe easiest way to learn Git is to start with its file formats and\nwork up to the commands.\n---snap---\n\nWe have heard this sort of feedback for years. But we have been unable\nto adequately write our own documentation or clean up our man pages to\nbe useful to the average person who doesn't know why the --no-frobbing\noption doesn't disable the --frobinator option to the\n--frobbing-subcommand of git frob.  :(\n\nhttp://git-man-page-generator.lokaltog.net/ shouldn't exist and\nshouldn't be funny. Yet it does. :(\n"},{"id":"256950","messageId":"xmqqwq2x8y0m.fsf@gitster.dls.corp.google.com","threadId":"38674","inReplyTo":"CAJo=hJuKL3akaG3Xh8mH5iij_dAdMkBW8fQgvreOsUHV517gpw@mail.gmail.com","subject":"Re: An interesting opinion on DVCS/git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-03T23:24:57Z","receivedAt":"2015-03-03T23:24:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> We have heard this sort of feedback for years. But we have been unable\n> to adequately write our own documentation or clean up our man pages to\n> be useful to the average person who doesn't know why the --no-frobbing\n> option doesn't disable the --frobinator option to the\n> --frobbing-subcommand of git frob.  :(\n\nIIU/RC, GSoC is not only about coding.  Perhaps doing a proper\ntechnical editing of the manual pages could be a summer project, to\nwhich GitHub or somebody more skilled than us developers can supply\nmentorship?\n"},{"id":"256953","messageId":"003f01d0560d$80bd7d50$823877f0$@nexbridge.com","threadId":"38674","inReplyTo":"CAJo=hJuKL3akaG3Xh8mH5iij_dAdMkBW8fQgvreOsUHV517gpw@mail.gmail.com","subject":"RE: An interesting opinion on DVCS/git","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2015-03-03T23:55:17Z","receivedAt":"2015-03-03T23:55:17Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"\n> On 03 Mar 2015, Shawn Pearce Wrote:\n>> On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@google.com> wrote:\n> > bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity\n> \n> Indeed, a DVCS like Git or Hg does not fit everyone. And neither do centralized\n> systems like Subversion. Choice is good.\n> \n> However... I found some passages troubling for Git, e.g.:\n> \n> ---snip---\n> Git is so amazingly simple to use that APress, a single publisher, needs to have\n> three different books on how to use it. It’s so simple that Atlassian and GitHub\n> both felt a need to write their own online tutorials to try to clarify the main Git\n> tutorial on the actual Git website. It’s so transparent that developers routinely\n> tell me that the easiest way to learn Git is to start with its file formats and work\n> up to the commands.\n> ---snap---\n> \n> We have heard this sort of feedback for years. But we have been unable to\n> adequately write our own documentation or clean up our man pages to be\n> useful to the average person who doesn't know why the --no-frobbing option\n> doesn't disable the --frobinator option to the --frobbing-subcommand of git\n> frob.  :(\n\nIn real life, I do process automation, so I'm coming at this from a slightly different point of view. What appeals to me about git is the richness of processes that can be implemented with it. You may want to consider it a complex process enabler engine that happens to do DVCS. Having built one of these also, and being saddled with huge numbers of requirements, I can say from experience that complexity is a side effect of doing what you need to do. Like many complex products, git takes on a life of its own, and obviously chose completeness instead of simplicity as a goal. Personally, I am not complaining, but I hear the complaints too. The bigger complaints are when you cannot do your job because the engine is not rich enough (see anything derived from SCCS - yes saying that shows my hair colour), which forced my company *to* git. \n\nWhen looking at git, I personally feel that it is important to deploy simple-to-use scripts and instructions to implement the process you want to use - and I hate to leave a footprint saying this, but, people are fundamentally lazy about non-goal activities. Thinking about mundane tasks like committing and delivering is outside the typical work-instruction box, but if, as a repository manager, you need a rich engine, spend the couple of days and script it. I think the objections in the article are essentially sound, from one point of view, but omit the core domain-space of why git is around and necessary, as opposed to many other unnamed RCS-like systems that are *not* sufficient.\n\n> http://git-man-page-generator.lokaltog.net/ shouldn't exist and shouldn't be\n> funny. Yet it does. :(\n\nMockery is the not the kindest form of flattery, but it sure is the sincerest. I've been the target of this too. Laugh, and suggest workflows. And, for the record, the only way you will remove atomicity/immutability of changes is out of my cold dead hands. :)\n\nCheers,\nRandall\n"},{"id":"256954","messageId":"alpine.DEB.2.02.1503031642340.26501@nftneq.ynat.uz","threadId":"38674","inReplyTo":"CAJo=hJuKL3akaG3Xh8mH5iij_dAdMkBW8fQgvreOsUHV517gpw@mail.gmail.com","subject":"Re: An interesting opinion on DVCS/git","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2015-03-04T00:53:34Z","receivedAt":"2015-03-04T00:53:34Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Tue, 3 Mar 2015, Shawn Pearce wrote:\n\n> On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@google.com> wrote:\n>> bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity\n>\n> Indeed, a DVCS like Git or Hg does not fit everyone. And neither do\n> centralized systems like Subversion. Choice is good.\n>\n> However... I found some passages troubling for Git, e.g.:\n>\n> ---snip---\n> Git is so amazingly simple to use that APress, a single publisher,\n> needs to have three different books on how to use it. It’s so simple\n> that Atlassian and GitHub both felt a need to write their own online\n> tutorials to try to clarify the main Git tutorial on the actual Git\n> website. It’s so transparent that developers routinely tell me that\n> the easiest way to learn Git is to start with its file formats and\n> work up to the commands.\n> ---snap---\n>\n> We have heard this sort of feedback for years. But we have been unable\n> to adequately write our own documentation or clean up our man pages to\n> be useful to the average person who doesn't know why the --no-frobbing\n> option doesn't disable the --frobinator option to the\n> --frobbing-subcommand of git frob.  :(\n>\n> http://git-man-page-generator.lokaltog.net/ shouldn't exist and\n> shouldn't be funny. Yet it does. :(\n\nAs for the different online tutorials, I'll point out that every university that \nsupports it's students using Thunderbird has it's own version of a tutorial on \nhow to use and configure Thunderbird. The question is if they are coverying \ntheir one use case of how to use git with their service, or if they are trying \nto duplicate the git documentation.\n\n\nThere are two reasons for having multiple books out for a piece of software\n\n1. the software is horribly complicated to use, even for beginners\n\n2. the software is extremely powerful, to to understand all the different \nadvanced options, and when to use them, takes a lot of explination\n\nIn the case of git, there's a bit of both.\n\nPart of the problem is that there are so many different ways to use it (all in \ncommon use) that there isn't one simple set of insructions that will be right in \nall the different use cases (thus the value of services that force users to \noperate in one specific model providing a tutorial in how to use it with their \nservice)\n\nAt this point, Internet Lore says \"git is hard to use\", and if you approach any \nsoftware with that attitude, you will find lots of things to point at to justify \nyour opinion.\n\nI'm not saying that there isn't room for improvement, I'm just saying that the \nevidence provided is not as one-sided as they make it sound.\n\nDavid Lang"},{"id":"257004","messageId":"54F723D3.1050805@drmicha.warpmail.net","threadId":"38674","inReplyTo":"alpine.DEB.2.02.1503031642340.26501@nftneq.ynat.uz","subject":"Re: An interesting opinion on DVCS/git","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-03-04T15:25:07Z","receivedAt":"2015-03-04T15:25:07Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"David Lang venit, vidit, dixit 04.03.2015 01:53:\n> On Tue, 3 Mar 2015, Shawn Pearce wrote:\n> \n>> On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@google.com> wrote:\n>>> bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity\n>>\n>> Indeed, a DVCS like Git or Hg does not fit everyone. And neither do\n>> centralized systems like Subversion. Choice is good.\n>>\n>> However... I found some passages troubling for Git, e.g.:\n>>\n>> ---snip---\n>> Git is so amazingly simple to use that APress, a single publisher,\n>> needs to have three different books on how to use it. It’s so simple\n>> that Atlassian and GitHub both felt a need to write their own online\n>> tutorials to try to clarify the main Git tutorial on the actual Git\n>> website. It’s so transparent that developers routinely tell me that\n>> the easiest way to learn Git is to start with its file formats and\n>> work up to the commands.\n>> ---snap---\n>>\n>> We have heard this sort of feedback for years. But we have been unable\n>> to adequately write our own documentation or clean up our man pages to\n>> be useful to the average person who doesn't know why the --no-frobbing\n>> option doesn't disable the --frobinator option to the\n>> --frobbing-subcommand of git frob.  :(\n>>\n>> http://git-man-page-generator.lokaltog.net/ shouldn't exist and\n>> shouldn't be funny. Yet it does. :(\n> \n> As for the different online tutorials, I'll point out that every university that \n> supports it's students using Thunderbird has it's own version of a tutorial on \n> how to use and configure Thunderbird. The question is if they are coverying \n> their one use case of how to use git with their service, or if they are trying \n> to duplicate the git documentation.\n> \n> \n> There are two reasons for having multiple books out for a piece of software\n> \n> 1. the software is horribly complicated to use, even for beginners\n> \n> 2. the software is extremely powerful, to to understand all the different \n> advanced options, and when to use them, takes a lot of explination\n> \n> In the case of git, there's a bit of both.\n> \n> Part of the problem is that there are so many different ways to use it (all in \n> common use) that there isn't one simple set of insructions that will be right in \n> all the different use cases (thus the value of services that force users to \n> operate in one specific model providing a tutorial in how to use it with their \n> service)\n> \n> At this point, Internet Lore says \"git is hard to use\", and if you approach any \n> software with that attitude, you will find lots of things to point at to justify \n> your opinion.\n> \n> I'm not saying that there isn't room for improvement, I'm just saying that the \n> evidence provided is not as one-sided as they make it sound.\n> \n> David Lang\n> \n\nYes, that article has a few really weak lines of arguments, such as the\ntutorial count.\n\nAlso, that advice to \"learn git from the file formats\", which I hope\nmeans something like \"learn the structure, not recipes\" is good advice\nfor learning any powerful toolset - rediculing it is not quite a proof\nof intelligence.\n\nAnd I don't think there's anything we have to regret about the basic\narchitecture of (the DAG/object structure of) git. (OK, the various\nsignature formats ;)\n\nThat being said, we all know how often we want to change the UI and\nbackwards compatibility keeps us from doing so. The UI could really\nbenefit from a fresh start, where, based on what we know now, we first\nthink about:\n\n- How do we structure/denote subcommands within commands? E.g. to dash\nor not to dash, default subcommand etc.\n\n- How do we structure \"read\" commands vs. \"write\" commands? E.g. the\npairs \"branch [-l]\"/\"branch <name>\", \"log\"/\"commit\" etc.\n\n- How do we name options consistently? E.g. -n=--dry-run everywhere\n\n- How do we make working with the special git concepts more natural?\nE.g. index, detached heads.\n\nMichael\n"},{"id":"257125","messageId":"54F91E25.4050008@gmail.com","threadId":"38674","inReplyTo":"54F723D3.1050805@drmicha.warpmail.net","subject":"Re: An interesting opinion on DVCS/git","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2015-03-06T03:25:25Z","receivedAt":"2015-03-06T03:25:25Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 03/04/2015 08:55 PM, Michael J Gruber wrote:\n\n> Yes, that article has a few really weak lines of arguments, such as the\n> tutorial count.\n\nHere's his definition of the main draw of a DVCS:\n\n    No, the only thing that a DVCS gets you, by definition, is that\n    everyone gets a copy of the full offline history of the entire\n    repository to do with as you please.\n\nThat completely misses the point.  What about committing while offline,\n'git blame' months-old changes offline, or local branches that don't\nhave to make it to the server until they have cooked for a while, and so\non and on?\n\nWe're not all \"facebooks\" with multi-GB repos, and I certainly don't\ncare as much about disk space or bandwidth if losing those features is\nthe cost.\n\nIt gets worse:\n\n    Let me tell you something. Of all the time I have ever used DVCSes,\n    over the last twenty years if we count Smalltalk changesets and\n    twelve or so if you don’t, I have wanted to have the full history\n    while offline a grand total of maybe about six times.\n\nI don't know how you can work on anything reasonably complex and\nmulti-developer without using some of those features six times in a\n*week* (sometimes, six times in a *weekend*) let alone 12 years.\n"},{"id":"257404","messageId":"4949A08A7B0445C2953FDB0F0C870BF0@PhilipOakley","threadId":"38674","inReplyTo":"CAGZ79kZ8CrjwVh3+OHSV1tv+fRXaDZ_diOO5E7QnSLZ=HTFSfg@mail.gmail.com","subject":"Re: An interesting opinion on DVCS/git","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2015-03-09T14:31:27Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Stefan Beller\" <sbeller@google.com>\nSent: Monday, March 02, 2015 3:29 AM\n> bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity\n> --\n\nThe part that the author misses is not all the nice (or not so) stuff \nabout having a copy of the full repository locally, for all the reasons \nhe mentions, rather it is the *distribution of control*.\n\nIn most centralised repo systems there is also centralisation of \ncontrol. The user does not have control. I may initiate a request for \nchange, but it's authorisation is always somewhere else, to avoid my \naccidental pollution of the golden source.\n\nThe thing that a DVCS brings to the user is an ability to regain a \nlittle control of their own environment and to include version recording \nwithin it. The fact that it can be integrated seamlessly into the golden \nsource makes it a great tool providing a win-win for all, especially \nwhen a Hub environment provides a separation between the golden source \nand the user's perambulations and peregrinations that they'd like on a \nsafe server.\n\nIt is the distribution of Control, not the distribution of Code that \nmakes DVCS such a winner (for users). The distribution of all the code \nis icing on the cake (though natural in a FOSS project).\n--\nPhilip \n"}]}