> On 03 Mar 2015, Shawn Pearce Wrote: >> On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html