git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: David Abrahams <dave@boostpro.com>
Cc: git@vger.kernel.org
Subject: Re: friendlier names
Date: Tue, 27 Jan 2009 07:38:37 -0800	[thread overview]
Message-ID: <20090127153837.GB1321@spearce.org> (raw)
In-Reply-To: <87mydc6a2r.fsf@mcbain.luannocracy.com>

David Abrahams <dave@boostpro.com> wrote:
> 
> For example, why couldn't the "index" be called the "stage" instead?
> That, along with knowing that "git add" was a synonym for "git stage"
> would have flattened the learning curve considerably for me.

Historical reasons...

Waaay back the "index" was an index of the files git knows about in
your working directory.  It made sense to call it an index, as like
a book index it was a full listing of what's here, sorted by name.

That's pre-1.0 days.  Like the very first version Linus ever
released.  Aka commit e83c5163316f89bfbde7d9ab23ca2e25604af290.

Much, much later, over many months, the index morphed into what
you see today, which is a "staging area", accessed by "git add".

This was all incremental, in small parts.  Nobody set out to
design a "staging area" or to have "staging actions".  Back
when it was really the index you updated it with a tool called
git-update-index.  Adding new files required the --add flag.

People found --add annoying, so they wrote "git add" as a
wrapper around it.  But modified existing files still had
to be updated with git-update-index.  Then someone pointed
out that add of an existing file and add of a new file are
similiar enough that they should just be the same command,
"git add".

Only late last October at the GitTogether did we start to talk about
creating a command called "git stage", because people have started to
realize we seem to call it a "staging area" as we train newcomers...

The tools are _all_ slowly evolved over time.  Nothing in git
was ever set out from the beginning as a "this is what we are
going to do".  The only part of Git that is like that is the core
data structure on disk for the object store.  That hasn't changed
since Linus switched from SHA1(COMPRESS(data)) to SHA1(data) for
the object naming algorithm, and even that was done in the first
couple of weeks.

-- 
Shawn.

  parent reply	other threads:[~2009-01-27 15:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-27 15:30 David Abrahams
2009-01-27 15:33 ` Felipe Contreras
2009-01-27 15:38 ` Shawn O. Pearce [this message]
2009-01-27 16:40   ` David Abrahams
2009-01-27 18:10   ` Johannes Schindelin
2009-01-27 18:28   ` Junio C Hamano
2009-01-27 19:17     ` Jakub Narebski
2009-01-27 19:50       ` Junio C Hamano
2009-01-28  2:12         ` Jakub Narebski
2009-01-28  4:51           ` Junio C Hamano

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

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

  git send-email \
    --in-reply-to=20090127153837.GB1321@spearce.org \
    --to=spearce@spearce.org \
    --cc=dave@boostpro.com \
    --cc=git@vger.kernel.org \
    --subject='Re: friendlier names' \
    /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

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 NNTP newsgroup(s).