git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Shawn Pearce'" <spearce@spearce.org>,
	"'Stefan Beller'" <sbeller@google.com>
Cc: <git@vger.kernel.org>
Subject: RE: An interesting opinion on DVCS/git
Date: Tue, 3 Mar 2015 18:55:17 -0500	[thread overview]
Message-ID: <003f01d0560d$80bd7d50$823877f0$@nexbridge.com> (raw)
In-Reply-To: <CAJo=hJuKL3akaG3Xh8mH5iij_dAdMkBW8fQgvreOsUHV517gpw@mail.gmail.com>


> On 03 Mar 2015, Shawn Pearce Wrote:
>> On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@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

  parent reply	other threads:[~2015-03-03 23:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <54F2CD12.8050609@gmail.com>
2015-03-02  3:29 ` Fwd: An interesting opinion on DVCS/git Stefan Beller
2015-03-03 22:49   ` Shawn Pearce
2015-03-03 23:24     ` Junio C Hamano
2015-03-03 23:55     ` Randall S. Becker [this message]
2015-03-04  0:53     ` David Lang
2015-03-04 15:25       ` Michael J Gruber
2015-03-06  3:25         ` Sitaram Chamarty
2015-03-09 14:47   ` Philip Oakley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='003f01d0560d$80bd7d50$823877f0$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=git@vger.kernel.org \
    --cc=sbeller@google.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).