commit: Record changes locally

Usage:
  eg commit [-a|--all-known] [-b|--bypass-unknown-check]
            [--staged|-d|--dirty] [-F FILE | -m MSG | --amend] [--]
            [FILE...]

Description:
  Records changes locally along with a log message describing the
  changes you have made.  If no -F or -m option is supplied, an editor
  is opened for you to enter a log message.

  In order to prevent common errors, the commit will abort with a warning
  message if there are no changes to commit, there are conflicts from a
  merge, or if eg detects that the choice of what to commit is ambiguous.
  In particular, if you have any "newly created" unknown files present,
  or if you have both staged changes (i.e. changes explicitly marked as
  ready for commit) and unstaged changes, then you will get a warning
  rather than having the commit occur.  You can run 'eg status' to get the
  status of various files and their changes.  These commit checks can be
  bypassed with various options.

Examples:
  Record current changes locally, not changing anything in CVS...OR...get
  a warning message if eg detects that the choice of what to commit is not
  necessarily clear.
      $ eg commit

  Record current changes, ignoring any unknown files present.  Also
  remember the list of unknown files so that their existence will not
  trigger future "You have new unknown files present" warnings when not
  using the -b flag.
      $ eg commit -b

  Record brand new file and current changes.
      $ eg stage file.c
      $ eg commit -a
  Note: Running 'eg stage FILE' explicitly marks FILE as being ready to
  commit.  Since you likely haven't explicitly marked your other changes as
  ready to commit, pass the -a flag to specify that both kinds of changes
  should be recorded.

  (Advanced) Record staged changes, ignoring both unstaged changes and
  unknown files.
      $ eg commit --staged

Options:
  --all-known, -a
    (Could also be called --act-like-other-vcses).  Commit both staged
    (i.e. explictly marked as ready for commit) changes and unstaged
    changes.

    Incompatible with explicitly specifying files to commit on the command
    line, and incompatible with the --staged option.

  --bypass-unknown-check, -b
    Commit local changes, even if there are unknown files around.  If this
    flag is not used and unknown files are currently present that were not
    present the last time the -b flag was used, then the commit will be
    aborted with a warning message.

  --staged, --dirty, -d
    Commit only staged changes and bypass sanity checks.  ("dirty" is kept
    as a synonym in order to provide a short (-d) form.  The term "dirty"
    is used to convey the fact that the working area will likely not be
    "clean" after a commit since unstaged changes will still be present).

    WARNING: Do not try to use -s as a shorthand for --staged; -s has a
    different meaning (see 'git commit --help')

    Incompatible with explicitly specifying files to commit on the command
    line, and incompatible with the --all-known option.

  -F FILE
    Use the contents of FILE as the commit message

  -m MSG
    Use MSG as the commit message.

  --amend
    Amend the last commit on the current branch.

Differences from git commit:
  The "--staged" (and "-d" and "--dirty" aliases) are unique to eg commit;
  git commit behavior differs from eg commit in that it acts by default
  like the --staged flag was passed UNLESS either the -a option is passed
  or files are explicitly listed on the command line.

  The "--bypass-unknown-check" is unique to eg commit; git commit
  behavior differs by always turning on this functionality -- there is
  no way to have git commit do an unknown files sanity check for you.

  "-a" is not nearly as useful for eg commit as it is for git commit.  "-a"
  has the same behavior in both, but the "smart" behavior of eg commit
  means it is only rarely needed.

  The "--all-known" alias for "-a" is known as "--all" to git-commit; I
  find the latter confusing and misleading and thus renamed to the former
  for eg commit.

  To be precise about the behavior of a plain "eg commit":
     If the working copy is clean                -> warn user: nothing to commit
     else if there are unmerged files            -> warn user: unmerged files
     else if there are new untracked files       -> warn user: new unknown files
     else if both "staged" & unstaged changes[1] -> warn user: mix
     else                                        -> run "git commit -a"
  Actually, I do not pass -a if there are only staged changes present, but
  the result is the same.  Note that this essentially boils down to making
  the user do less work (no need to remember -a in the common case) and
  extending the sanity checks git commit does (which currently only covers
  the clean working copy case) to also prevent a number of other very
  common user pitfalls.

  [1] The reason for putting "staged" in quotes comes from the case of
  running "eg commit --amend" when you have local unstaged changes.  Does
  the user want to merely amend the prior commit message or add their
  changes to the previous commit?  (Even if the index matches HEAD at this
  time, we are committing relative to HEAD^1.)  It is not clear what the
  user wants, so we warn and ask them to use -a or --staged.

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