Sharan Basappa <> writes:
> Git mentions that state of the file as untracked, unmodified, modified and 
> staged.
> 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.


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 
For more options, visit

Reply via email to