----- Original Message ----- From: "Dale R. Worley" <wor...@alum.mit.edu>
To: <git-users@googlegroups.com>
Sent: Friday, May 20, 2016 11:14 PM
Subject: Re: [git-users] Git life cycle

Sharan Basappa <sharan.basa...@gmail.com> writes:
Git mentions that state of the file as untracked, unmodified, modified and

As I understand untracked files are not yet in the respository.
unmodified and modified is understood but what action results in a file
being in staged state?
is it git add or git commit?

I had trouble with these terms myself.  The problem is that the
situation is a bit complex, and few Git references stop to carefully and
exactly define the terms.  I eventually wrote myself a guide to Git, and
within it is this definition of those terms:


 A commit is not created as a copy of the working copy directory tree,
 but rather of a shadow directory tree called the *index* (or
 sometimes, the *cache*).  This makes it easier to control exactly
 which changes in the working copy are included in a commit.  Note that
 despite its name, the index does not contain *references* to files in
 the working copy directory tree, but rather *fixed copies* of those
 files, and the index's contents can differ from the working copy.

 Generally, the index contains either the contents of the base commit,
 or those contents plus some or all of the modifications that are in
 the working copy.  The names of the files that differ between the
 working copy, the index, and the base commit are shown by the "git
 status" command.  The contents of the files are compared by the "git
 diff" command.  New or changed files in the working copy can be copied
 to the index with "git add".  The output of "git status" shows example
 commands to add or remove changes from the current state of the index.
 Files can be removed from the index with "git rm".

File classification

 Files in the working copy are classified into three groups.  Which
 group a file is in determines the effect many Git commands have on it.

   A file is tracked if it is in the base commit of the repository or
   if it is in the index.  Git commands that are intended to apply to
   "all" files generally apply to all tracked files.
   If a file is ignored, it is not operated on by Git commands that
   do not explicitly specify it.  There are several mechanisms for
   specifying which files should be ignored, of which the ".gitignore"
   file is the most common.  Any directory can contain a ".gitignore"
   file, which (in the simplest case) contains a (newline-separated)
   list of filename globs.  Any file whose name matches a glob in the
   ".gitignore" file of its directory, or the ".gitignore" file of any
   ancestor directory (up to the top directory of the repository) is
   ignored.  Similarly, a ".gitignore" file can contain a glob preceded
   by "/".  That glob only applies to file files in the directory
   containing the ".gitignore" file.  (See the "gitignore" manual page
   for the full details.)  The ".gitignore" files should be
   version-controlled files in the repository.
   All files that are neither tracked nor ignored are considered
   untracked.  Git assumes that you may want to track them at some
   future time.


+1 for the nice explanation.

minor extra:
The Index is also commonly called the *staging area* when viewed from an outward facing perspective (i.e. what do users do), with index being more commonly used for an inward facing perspective (e.g. for code development). There is currently a truce about which is the 'right name'!
You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to