Re: Terminology question about remote branches.

Theodore Tso [off-list ref] writes:

To use a GNU emacs example, consider M-x customize, which is this
huge, very fancy, *very* complex hierarchical mechanism with a
pointy-clicky interface for setting options.  Most emacs experts
wouldn't use it, preferring to open code raw emacs-lisp settings in
their .emacs.el.  If you ask an old-time emacs user how to set up
some specific feature setting via M-x customize, they might look at
you blankly, because it's not an interface they use much, if at all.

Well, let me throw you back one of your questions: do you have any
statistics backing this up?

As to anecdotal evidence: I am an old-time Emacs user, and I pretty
much use customize _exclusively_ since it generally leaves me with a
_working_ configuration even when the DOC string might be sub-optimal
or misleading or hard to understand, and it makes sure that, say,
everything to make a global minor mode _active_ (like loading some
file, or calling some initialization functions) is done at the right
point of time.

If "old-time Emacs users" would not use customize, why would pretty
much _every_ package come with _working_ defcustoms?  Who writes and
_tests_ those defcustoms if not the "old-time Emacs users"?

A similar thing can be said of "git branch"; once you are familiar
with how git works at a conceptual level, it can often be
faster/easier to just hack the .git/config file directly, instead of
using "git branch" to set up things the way you want.  And I'm
pretty sure there are ways to set up the config file when you edit
it by hand that you can't set up via "git branch".

Sure.  But we don't want to _require_ this sort of special knowledge
before one can even hope to do some basic task.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum