status: Summarize current changes

Usage:
  eg status

Description:
  Show the current state of the project.  In addition to showing the
  currently active branch, whether you have unpushed local commits,
  whether you have stashed any sets of changes away (see 'eg help
  stash'), this command will list files with content in any of the
  following states:

     Unknown files
       Files that are not explicitly ignored (i.e. do not appear in an
       ignore list such as a .gitignore file) but whose contents are still
       not tracked by git.

       These files can become known by running 'eg stage FILENAME', or
       ignored by having their name added to a .gitignore file.

     Newly created unknown files
       Same as unknown files; the reason for splitting unknown files into
       two sets is to make it easier to find the files users are more
       likely to want to add.  Also, 'eg commit' will by default error out
       with a warning message if there are any newly created unknown files
       in order to prevent forgetting to add files that should be included
       in a commit.

     Modified submodules:
       subdirectories that are tracked under their own git repository, and
       that are being tracked via use of the 'git submodule' command.

     Changed but not updated ("unstaged")
       Files whose contents have been modified in the working copy.

       (Advanced usage note) If you explicitly mark all the changes in a
       file as ready to be committed, then the file will not appear in this
       list and will instead appear in the "staged" list (see below).
       However, a file can appear in both the unstaged and staged lists if
       only part of the changes in the file are marked as ready for commit.

     Unmerged paths (files with conflicts)
       Files which could not be automatically merged.  If such files are
       text files, they will have the typical conflict markers.  These
       files need to be manually edited to give them the correct contents,
       and then the user should inform git that the conflicts are resolved
       by running 'eg resolved FILENAME'.

     Changes ready to be committed ("staged")
       Files with content changes that have explicitly been marked as ready
       to be committed.  This state only typically appears in advanced
       usage.

       Files enter this state through the use of 'eg stage'.  Files can
       return to the unstaged state by running 'eg unstage' See 'eg help
       topic staging' to learn about the staging area.


Differences from git status:
  eg status output is essentially just a streamlined and cleaned version of
  git status output, with the addition of a new section (newly created
  untracked files) and an extra status message being displayed when in the
  middle of a special state (am, bisect, merge, or rebase).

  The streamlining serves to avoid information overload to new users (which
  is only possible with a less error prone "commit" command) and the
  cleaning (removal of leading hash marks) serves to make the system more
  inviting to new users.

  A slight wording change was done to transform "untracked" to "unknown"
  since, as Havoc pointed out, the word "tracked" may not be very self
  explanatory (in addition to the real meaning, users might think of:
  "tracked in the index?", "related to remote tracking branches?", "some
  fancy new monitoring scheme unique to git that other vcses do not have?",
  "is there some other meaning?").  I do not know if "known" will fully
  solve this, but I suspect it will be more self-explanatory than
  "tracked".

  There are also slight changes to the section names to reinforce
  consistent naming when referring to the same concept (staging, in this
  case), but the changes are very slight.

  The extra status message when in the middle of an am, bisect, merge,
  or rebase serves two purposes: to remind users that they are in the
  middle of some operation (some people don't use the special prompt
  from git's bash-completion support), and to provide a command users
  can run to get help resolving such situations.  (Many users were
  confused about or unaware how to resolve incomplete merges and
  rebases; providing them with a specially written help page they
  could access seemed to effectively assist them figure out the
  appropriate steps to take -- especially in tricky or special cases.)

See also
  Run 'man git-status' for a comprehensive list of options available.
  eg status is designed to accept the same options as git status, and
  with the same meanings unless specified otherwise in the above
  "Differences" section.