Summary of changes:
  Modified Behavior:
    apply
    branch
    bundle
    checkout
    cherry-pick
    clone
    commit
    diff
    help
    log
    pull
    push
    rebase
    reset
    revert
    rm
    stash
    status
  New commands:
    cat
    changes
    difftool
    info
    publish
    resolved
    squash
    stage
    switch
    track
    unstage
    update
  Modified Help Only:
    add
    config
    gc
    init
    merge
    remote
    tag
Changes to apply:
  eg apply is identical to git apply except that it accepts --staged as a
  synonym for --cached.
Changes to branch:
  eg branch is identical to git branch other than adding a new -s option for
  switching to a branch immediately after creating it.
Changes to bundle:
  eg bundle differs from git bundle in two ways:
    (1) eg bundle defaults to "--all HEAD" if no revisions are passed to create
    (2) eg bundle provides a create-update subcommand
Changes to cat:
  The output of "git show FILE" is probably confusing to users at first,
  as is the need to specify files relative to the top of the git project
  rather than relative to the current directory.  Thus, "eg cat FILE"
  calls "git show HEAD:PATH/TO/FILE".
Changes to changes:
  eg changes is unique to eg; git does not have a similar command.
Changes to checkout:
  eg checkout accepts all parameters that git checkout accepts with the
  same meanings and same output (eg checkout merely calls git checkout in
  such cases).

  The only difference between eg and git regarding checkout is that eg
  checkout will also accept all arguments to git clone, and then tell users
  that they must have meant to run eg clone (a much nicer error message for
  users trying to get a copy of source code from a remote repository than
  "fatal: Not a git repository").
Changes to cherry-pick:
  eg cherry-pick contains both the functionality of git cherry-pick and git
  revert.  If the -R option is specified, eg cherry-pick calls git revert
  (after removing the -R option); otherwise it calls git cherry-pick.
Changes to clone:
  eg clone and git clone are very similar, but eg clone by default sets up
  a branch for each remote branch automatically (instead of only creating
  one branch, typically master).
Changes to 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.
Changes to diff:
  Changes to eg diff relative to git diff are:
    (1) Different defaults for what to diff relative to
    (2) Providing a more consistent double-dot operator

  Section 1: Different defaults for what to diff relative to

  The following illustrate the two changed defaults of eg diff:
    eg diff            <=> git diff HEAD
    eg diff --unstaged <=> git diff
  (Which is not 100% accurate due to merges; see below.)  In more detail:

  The "--unstaged" option is unique to eg diff; to get the same behavior
  with git diff you simply list no revisions and omit the "--cached" flag.

  When neither --staged nor --unstaged are specified to eg diff and no
  revisions are given, eg diff will pass along the revision "HEAD" to git
  diff.

  The "--staged" option is an alias for "--cached" unique to eg diff; the
  purpose of the alias is to reduce the number of different names in git
  used to refer to the same concept.  (Update: the --staged flag is now
  part of git with the same meaning as in eg.)

  Merges: The above is slightly modified if the user has an incomplete
  merge; if the user has conflicts during a merge (or uses --no-commit when
  calling merge) and then tries "eg diff", it will abort with a message
  telling the user that there is no "last" commit and will provide
  alternative suggestions.

  Section 2: Providing a more consistent double-dot operator

    The .. operator of git diff (e.g. git diff master..devel) means what
    the ... operator of git log means, and vice-versa.  This causes lots of
    confusion.  We fix this by aliasing making the .. operator of eg diff
    do exactly what the ... operator of git diff does.  To see why:
    
    Meanings of git commands, as a reminder (A and B are revisions):
      git diff A..B  <=> git diff A B                      # Endpoint difference
      git diff A...B <=> git diff $(git merge-base A B) B  # Changes from base
    
    Why this is confusing (compare to above):
      git log A..B  <=> git log ^$(git merge-base A B) B   # Changes from base
      git log A...B <=> git log A B ^$(git merge-base A B) # Endpoint difference
    
    So, my translation:
      eg diff A B   <=>  git diff A B    <=> git diff A..B
      eg diff A..B  <=>  git diff A...B
      eg diff A...B <=>  git diff A...B

    Reasons for this change:
      * New users automatically get sane behavior, and use either eg diff A B
        or eg diff A..B, each doing what one would expect.  They do not ever
        realize that A...B is a bit weird because they have no need to try to
        use it; eg diff A B covers their needs.
      * Users worried about switching between eg and git without having to
        modify their command lines can always use either diff A B or
        diff A...B, but never any other form; using this subset ensures that
        both eg and git behave identically.
      * Users only access git diff A..B behavior through eg diff A B, which
        is less typing and makes more sense.
      * Since git diff A..B and git diff A B are the same, the latter is far
        more common, and the former is confusing, odds are that if any git
        user suggests someone use git diff A..B they probably really meant
        git diff A...B
Changes to difftool:
  git difftool behaves just like git diff, but launches an external tool
  instead of using git's built-in machinery.  eg diff is quite different from
  git diff (see 'eg help diff' for details); eg difftool behaves just like
  eg diff.
Changes to help:
  eg help uses its own help system, ignoring the one from git help...except
  that eg help will call git help if asked for help on a subcommand it does
  not recognize.

  'git help COMMAND', by default, simply calls 'man git-COMMAND'.  The git
  man pages are really nice for people who are experts with git; they are
  comprehensive and detailed.  However, new users tend to get lost in a sea
  of details and advanced topics (among other problems).  'eg help COMMAND'
  provides much simpler pages of its own and refers to the manpages for
  more details.  The eg help pages also list any differences between the eg
  commands and the git ones, to assist interested users in learning git.

  If you simply want a brief list of available options and descriptions,
  you may also want to try running 'git COMMAND -h' (which differs from
  the two identical commands 'git COMMAND --help' and 'git help COMMAND').
Changes to info:
  eg info is unique to eg; git does not have a similar command.  It
  originally was intended just to do something nice if svn converts happen
  to try this command, but I have found it to be a really nice way of
  helping users get their bearings.  It also provides some nice statistics
  that git users may appreciate (particularly when it comes time to fill
  out the Git User Survey).
Changes to log:
  eg log output differs from git log output by showing simpler revision
  identifiers that will be easier for new users to understand and use.
  In detail:
    eg log
  is essentially the same as
    git log | git name-rev --stdin --refs=$(git symbolic-ref HEAD) | less
  However, it implements the name-rev behavior internally to provide
  incremental history processing (which avoids slow upfront full-history
  analyses) in common cases.
Changes to publish:
  eg publish is unique to eg, designed to condense the multiple necessary
  steps with git into one (or a few) commands.  The steps that eg publish
  performs are essentially:
      if ( git config --get remote.REMOTE_ALIAS.url > /dev/null); then
        echo "REMOTE_ALIAS already defined"; false;
      fi &&
      ssh [USER@]MACHINE "
        test -d REMOTE_PATH && echo "REMOTE_PATH already exists!" && exit 1;
        if (! groups | grep "\bGROUP\b" > /dev/null); then
          echo "Cannot change to group GROUP";  exit 1;
        fi;
        if (! type -p git>/dev/null);then echo "Cannot find git"; exit 1; fi &&
        newgrp GROUP;
        mkdir -p REMOTE_PATH &&
        cd REMOTE_PATH &&
        git init [--shared] --bare &&
        touch git-daemon-export-ok &&
        (mv hooks/post-update.sample hooks/post-update || true) &&
        chmod u+x hooks/post-update" &&
      git remote add REMOTE_ALIAS [USER@]MACHINE:REMOTE_PATH &&
      git push
  Note that the command involving git-daemon-export-ok is only needed if
  you will be cloning/pulling from the repository via the git:// protocol
  (in which case you are responsible for running git-daemon on the remote
  machine), and the post-update hook related stuff is only necessary if you
  are trying to clone/pull via the http:// protocol (in which case you are
  responsible for running a webserver such as httpd on the remote machine);
  neither of these steps are needed if you are cloning/pulling via ssh, but
  they do not cause problems either.

  MULTI-USER NOTE: If you want multiple people to be able to push to the
  resulting repository, you will need to ensure that they all have ssh
  access to the machine, that they are all part of the same unix group, and
  that you use the --group option to ensure that the repository is set up
  to be shared by the relevant group.
Changes to pull:
  eg pull and git pull are nearly identical.  eg provides a slightly more
  meaningful name for --tags ("--all-tags"), introduces a new option
  named --branch, and tries to assist the user when no branch to
  merge/rebase is specified on the command line or in the config.

  The new --branch option (1) avoids the need to explain refspecs too early
  to users, (2) makes command line examples more self-documenting.  eg
  still accepts refspecs at the end of the commandline the same as git
  pull, however their explanation is deferred to 'eg help topic refspecs'.

  When no branch to merge/rebase is specified, eg pull will provide a list
  of known branches at the remote end.  In the special case that the remote
  has exactly one branch, eg will use that branch for merging/rebasing
  rather than erroring out.
Changes to push:
  eg push is largely the same as git push, despite attempts to simplify in
  a number of areas:

    (1) push.default=tracking is the default if push.default is unset (git
        uses push.default=matching if push.default is unset).  This seems
        to match the intuition of most former cvs/svn users, though it is
        my one dangerous default change for existing git users.  Tough
        call, since the 'safe' defaults for each group are unsafe and/or
        confusing for the other.  A new --matching-branches flag is added
        to get the old behavior (the plain ':' refspec from git does the
        same, but --matching-branches is more self-documenting and also
        predates the ':' refspec).

    (2) eg prevents pushing into a bare repository as a push-side check
        rather than a receive-side check (when it can determine that the
        remote repository is bare -- i.e. if the repository url is for a
        locally mounted filesystem or uses ssh).  eg also allows the check
        to be overridden on the push-side (by specifying a refspec
        containing a ':' character).  This means it can work for users of
        existing repositories (created with git < 1.7), and it provides a
        solution that both avoids working copy inconsistency for new users
        while allowing more advanced users to do what they need on the same
        repository, and without forcing users to twiddle with the
        configuration of the remote repository.  However, this method
        doesn't work for repositories accessed via git://, and only works
        for ssh-accessed repositories if users have ssh setup to not need a
        password (kerberos, ssh-keys, etc.).

    (3) eg performs checks for uncommitted changes and newly created
        unknown files and warns/aborts if such exist when the user pushes
        (most former cvs/svn users are not yet familiar with the fact that
        only committed stuff gets pushed/pulled).  As with eg commit, such
        checks can be overridden with the -b flag.

    (4) eg provides extra --tag and --branch flags to make command lines
        more self-documenting and to avoid excessively early introduction
        of refspecs (a very confusing topic for new users).  However,
        refspecs still work with eg push, and users can learn about them by
        running 'eg help topic refspecs'.
Changes to rebase:
  The only differences between eg rebase and git rebase are cosmetic;
  further, eg rebase accepts all options and flags that git rebase accepts.

  eg adds the identically behaved flags --since and --against in
  preference to using the position of the branch/revision name on the
  command line.  Note that
    git rebase master
  is somewhat confusing in that it isn't rebasing master but the current
  branch.  To make this clearer, eg allows (and encourages) the form
    eg rebase --against master
  The reason that both --against and --since flags were added (with
  identical behavior), is that the former makes for clearer command lines
  when the --onto flag is not also used.
Changes to reset:
  The only differences between eg reset and git reset are cosmetic;
  further, eg reset accepts all options and flags that git reset accepts.

  git reset uses option names of --soft, --mixed, and --hard.  While eg
  reset will accept these option names for compatibility, it provides
  alternative names that are more meaningful:
    --working-copy     <=> --hard
    --no-unstaging     <=> --soft
  There is no alternate name for --mixed, since it is the default and thus
  does not need to appear on the command line at all.

  The modified revert command of eg is encouraged for reverting specific
  files, though eg reset has the same file-specific reverting that git
  reset does.
Changes to resolved:
  eg resolved is a command new to eg that is not part of git.  It is
  almost synonymous with git add; however, there are two differences:
  (a) eg resolved will work on a locally deleted file in the unmerged
  state (git add will complain that there's 'No such file or
  directory', and some users have had difficulty trying to find out
  that they needed to run git rm on such files), (b) eg resolved only
  works on files in the unmerged state (reporting an error if files
  not in such a state are specified).
Changes to revert:
  eg revert is similar to the revert command of svn, hg, bzr, or darcs.  It
  is not provided by any one git command; it overlaps with about five
  different git commands in specific cases.  git users wanting the
  functionality in eg revert will typically be guided by expert git users
  towards whichever git command seems like the most natural fit for the
  particular case the user asks about.  Quite often, such users will
  continue using the command they are given for subsequent situations...and
  will often stumble across multiple cases where the git command no longer
  matches the wanted revert behavior.

  git does provide a command called revert, which is a subset of the
  behavior of eg cherry-pick:
    git revert COMMIT
  is the same as
    eg cherry-pick -R COMMIT
  which is, modulo the automatic commit message provided by git revert, the
  same as
    eg revert --in COMMIT && eg commit
  Note that while eg revert --in may look similar to git revert, the former
  is about undoing changes in just the working copy, is typically
  restricted to a specific subset of files, and is usually just one change
  of many towards testing or creating something new to be committed.  The
  latter is always concerned with reverse applying an entire commit, and is
  almost always used to immediately record that change.

  Note that git revert commands are invalid syntax in eg (since eg revert
  always requires the --since or --in flags to be specified whenever a
  commit is).  This means that eg can catch such cases and notify git
  users to adopt the eg cherry-pick -R command.

  Due to these changes, eg revert should be much more welcoming to users of
  svn, hg, bzr, or darcs.  It also provides a simple discovery mechanism
  for existing git users to allow them to easily work with eg.
  Additionally, these changes also make the reset and checkout/switch
  subcommands of eg easier to understand by limiting their scope instead of
  each having two very different capabilities.  (Technically, eg reset and
  eg checkout still have those capabilities for backwards compatibility, I
  just omit them in the documentation.)

  It seems that perhaps eg revert could be extended further, to accept
  things like
      \$ eg revert --in HEAD~8..HEAD~5 foo.c
  to allow reverting changes made in a range of commits.  The --in could
  even be optional in such a case, since the range makes it clear what is
  wanted.
Changes to rm:
  eg rm is identical to git rm except that it accepts --staged as a synonym
  for --cached.
Changes to squash:
  eg squash is a command new to eg that is not part of git.
Changes to stage:
  eg stage is a command new to eg that is not part of git (update: it is
  part of newer versions of git, with identical meaning to eg).  eg stage
  merely calls git add.
Changes to stash:
  eg stash is only cosmetically different than git stash, and is fully
  backwards compatible.

  eg stash list, by default, only shows the saved description -- not
  the reflog syntax or branch the change was made on.

  eg stash apply and eg stash show also accept any string and will
  apply or show the stash whose description contains that string.
  Although stash and apply accept reflog syntax (like their git stash
  counterparts), i.e. while
      $ eg stash apply stash@{3}
  will work, I think it will be easier for the user to run
      $ eg stash apply rudely interrupted changes
Changes to 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.)
Changes to switch:
  eg switch is a subset of the functionality of git checkout; the abilities
  and flags for creating and switching branches are identical between the
  two, just the name of the function is different.

  The ability of git checkout to get older versions of files is not part of
  eg switch; instead that ability can be found with eg revert.
Changes to track:
  eg track is unique to eg; git does not have a similar command.
Changes to unstage:
  eg unstage is a command new to eg that is not part of git; it is implemented
  on top of eg revert --staged, though it could as easily simply call through
  to git reset.
Changes to update:
  eg update is unique to eg; it exists primarily to ease the transition for
  cvs/svn users and to do something useful for them.  In particular, eg
  update is used just to do fast-forward updates when there are no local
  changes; if anything more than this is needed, eg advises users to run
  other commands.

  Here are the special cases eg update detects and provides tailored
  messages for:
    * User has local commits           => ask user to use eg pull instead
    * User provides argument to update => tell user to use eg switch for
                                          checking out an older revision or
                                          eg revert to undo changes to a file
    * User has locally deleted files   => tell user to use eg revert to
                                          undo local changes (and that they do
                                          not need to delete the file first as
                                          they did with cvs)
    * User has local modifications     => Tell user to stash or commit their
                                          changes before pulling updates
    * No default repository to contact => Tell user to run "eg remote add
                                          origin REPOSITORY_URL"
    * branch.BRANCH.merge not set and  => Warn user that we do not know which
      more than one remote branch         branch to pull from and suggest eg
      present                             pull or setting branch.BRANCH.merge