Re: An interesting opinion on DVCS/git
From: Stefan Beller sbel...@google.com Sent: Monday, March 02, 2015 3:29 AM bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity -- The part that the author misses is not all the nice (or not so) stuff about having a copy of the full repository locally, for all the reasons he mentions, rather it is the *distribution of control*. In most centralised repo systems there is also centralisation of control. The user does not have control. I may initiate a request for change, but it's authorisation is always somewhere else, to avoid my accidental pollution of the golden source. The thing that a DVCS brings to the user is an ability to regain a little control of their own environment and to include version recording within it. The fact that it can be integrated seamlessly into the golden source makes it a great tool providing a win-win for all, especially when a Hub environment provides a separation between the golden source and the user's perambulations and peregrinations that they'd like on a safe server. It is the distribution of Control, not the distribution of Code that makes DVCS such a winner (for users). The distribution of all the code is icing on the cake (though natural in a FOSS project). -- Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: An interesting opinion on DVCS/git
On 03/04/2015 08:55 PM, Michael J Gruber wrote: Yes, that article has a few really weak lines of arguments, such as the tutorial count. Here's his definition of the main draw of a DVCS: No, the only thing that a DVCS gets you, by definition, is that everyone gets a copy of the full offline history of the entire repository to do with as you please. That completely misses the point. What about committing while offline, 'git blame' months-old changes offline, or local branches that don't have to make it to the server until they have cooked for a while, and so on and on? We're not all facebooks with multi-GB repos, and I certainly don't care as much about disk space or bandwidth if losing those features is the cost. It gets worse: Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. I don't know how you can work on anything reasonably complex and multi-developer without using some of those features six times in a *week* (sometimes, six times in a *weekend*) let alone 12 years. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: An interesting opinion on DVCS/git
David Lang venit, vidit, dixit 04.03.2015 01:53: On Tue, 3 Mar 2015, Shawn Pearce wrote: On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller sbel...@google.com wrote: bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity Indeed, a DVCS like Git or Hg does not fit everyone. And neither do centralized systems like Subversion. Choice is good. However... I found some passages troubling for Git, e.g.: ---snip--- Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands. ---snap--- We have heard this sort of feedback for years. But we have been unable to adequately write our own documentation or clean up our man pages to be useful to the average person who doesn't know why the --no-frobbing option doesn't disable the --frobinator option to the --frobbing-subcommand of git frob. :( http://git-man-page-generator.lokaltog.net/ shouldn't exist and shouldn't be funny. Yet it does. :( As for the different online tutorials, I'll point out that every university that supports it's students using Thunderbird has it's own version of a tutorial on how to use and configure Thunderbird. The question is if they are coverying their one use case of how to use git with their service, or if they are trying to duplicate the git documentation. There are two reasons for having multiple books out for a piece of software 1. the software is horribly complicated to use, even for beginners 2. the software is extremely powerful, to to understand all the different advanced options, and when to use them, takes a lot of explination In the case of git, there's a bit of both. Part of the problem is that there are so many different ways to use it (all in common use) that there isn't one simple set of insructions that will be right in all the different use cases (thus the value of services that force users to operate in one specific model providing a tutorial in how to use it with their service) At this point, Internet Lore says git is hard to use, and if you approach any software with that attitude, you will find lots of things to point at to justify your opinion. I'm not saying that there isn't room for improvement, I'm just saying that the evidence provided is not as one-sided as they make it sound. David Lang Yes, that article has a few really weak lines of arguments, such as the tutorial count. Also, that advice to learn git from the file formats, which I hope means something like learn the structure, not recipes is good advice for learning any powerful toolset - rediculing it is not quite a proof of intelligence. And I don't think there's anything we have to regret about the basic architecture of (the DAG/object structure of) git. (OK, the various signature formats ;) That being said, we all know how often we want to change the UI and backwards compatibility keeps us from doing so. The UI could really benefit from a fresh start, where, based on what we know now, we first think about: - How do we structure/denote subcommands within commands? E.g. to dash or not to dash, default subcommand etc. - How do we structure read commands vs. write commands? E.g. the pairs branch [-l]/branch name, log/commit etc. - How do we name options consistently? E.g. -n=--dry-run everywhere - How do we make working with the special git concepts more natural? E.g. index, detached heads. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: An interesting opinion on DVCS/git
Shawn Pearce spea...@spearce.org writes: We have heard this sort of feedback for years. But we have been unable to adequately write our own documentation or clean up our man pages to be useful to the average person who doesn't know why the --no-frobbing option doesn't disable the --frobinator option to the --frobbing-subcommand of git frob. :( IIU/RC, GSoC is not only about coding. Perhaps doing a proper technical editing of the manual pages could be a summer project, to which GitHub or somebody more skilled than us developers can supply mentorship? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: An interesting opinion on DVCS/git
On 03 Mar 2015, Shawn Pearce Wrote: On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller sbel...@google.com wrote: bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity Indeed, a DVCS like Git or Hg does not fit everyone. And neither do centralized systems like Subversion. Choice is good. However... I found some passages troubling for Git, e.g.: ---snip--- Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands. ---snap--- We have heard this sort of feedback for years. But we have been unable to adequately write our own documentation or clean up our man pages to be useful to the average person who doesn't know why the --no-frobbing option doesn't disable the --frobinator option to the --frobbing-subcommand of git frob. :( In 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. When 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. http://git-man-page-generator.lokaltog.net/ shouldn't exist and shouldn't be funny. Yet it does. :( Mockery 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. :) Cheers, Randall -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: An interesting opinion on DVCS/git
On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller sbel...@google.com wrote: bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity Indeed, a DVCS like Git or Hg does not fit everyone. And neither do centralized systems like Subversion. Choice is good. However... I found some passages troubling for Git, e.g.: ---snip--- Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands. ---snap--- We have heard this sort of feedback for years. But we have been unable to adequately write our own documentation or clean up our man pages to be useful to the average person who doesn't know why the --no-frobbing option doesn't disable the --frobinator option to the --frobbing-subcommand of git frob. :( http://git-man-page-generator.lokaltog.net/ shouldn't exist and shouldn't be funny. Yet it does. :( -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: An interesting opinion on DVCS/git
On Tue, 3 Mar 2015, Shawn Pearce wrote: On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller sbel...@google.com wrote: bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity Indeed, a DVCS like Git or Hg does not fit everyone. And neither do centralized systems like Subversion. Choice is good. However... I found some passages troubling for Git, e.g.: ---snip--- Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands. ---snap--- We have heard this sort of feedback for years. But we have been unable to adequately write our own documentation or clean up our man pages to be useful to the average person who doesn't know why the --no-frobbing option doesn't disable the --frobinator option to the --frobbing-subcommand of git frob. :( http://git-man-page-generator.lokaltog.net/ shouldn't exist and shouldn't be funny. Yet it does. :( As for the different online tutorials, I'll point out that every university that supports it's students using Thunderbird has it's own version of a tutorial on how to use and configure Thunderbird. The question is if they are coverying their one use case of how to use git with their service, or if they are trying to duplicate the git documentation. There are two reasons for having multiple books out for a piece of software 1. the software is horribly complicated to use, even for beginners 2. the software is extremely powerful, to to understand all the different advanced options, and when to use them, takes a lot of explination In the case of git, there's a bit of both. Part of the problem is that there are so many different ways to use it (all in common use) that there isn't one simple set of insructions that will be right in all the different use cases (thus the value of services that force users to operate in one specific model providing a tutorial in how to use it with their service) At this point, Internet Lore says git is hard to use, and if you approach any software with that attitude, you will find lots of things to point at to justify your opinion. I'm not saying that there isn't room for improvement, I'm just saying that the evidence provided is not as one-sided as they make it sound. David Lang
