push: Push local commits to a published repository

Usage:
  eg push [--bypass-modification-check] [--branch BRANCH] [--tag TAG]
          [--all-branches] [--all-tags] [--mirror] REPOSITORY

Description:
  Push committed changes in the current repository to a published remote
  repository.  Note that this command cannot be used to create a new remote
  repository; use 'eg publish' (which both creates a remote repository and
  pushes to it) if you need to do that.

  The push can fail if the remote repository has commits not
  in the current repository; this can be fixed by pulling and merging
  changes from the remote repository (use eg pull for this) and then
  repeating the push.  Note that for getting changes directly to a fellow
  developer's clone, you should have them use 'eg pull' rather than trying
  to use 'eg push' on your end.

  Branches and tags are typically considered private; thus only the current
  branch will be involved by default (no tags will be sent).  The
  --all-branches, --matching-branches, --all-tags, and --mirror options
  exist to extend the list of changes included.  The --branch and --tag
  options can be used to specifically send different changes.

  See 'eg help topic remote-urls' for valid syntax for remote repositories.

  If you frequently push to the same repository, you may want to set up a
  nickname for it (see 'eg help remote'), so that you can specify the
  nickname instead of the full repository URL every time.  Also, if you want
  to change the default repository and branch to push to, see 'eg track'.

Examples:
  Push commits in the current branch
      $ eg push myserver.com:git-stuff/my-repo.git

  Push commits in all branches that already exist both locally and remotely
      $ eg push --matching-branches ssh://web.site/path/to/project.git

  Push commits in all branches, including branches that do no already exist
  remotely, and all tags, to the remote nicknamed 'alice'
      $ eg push --all-branches --all-tags alice

  Push all local branches and tags and delete anything on the remote end
  that is not in the current repository
      $ eg push --mirror ssh://jim@host.xz:22/~jim/project/published

  Create a two new tags locally, then push both
      $ eg tag MY_PROJECT_1_0
      $ eg tag USELESS_ALIAS_FOR_1_0
      $ eg push --tag MY_PROJECT_1_0 --tag USELESS_ALIAS_FOR_1_0

  Push the changes in just the stable branch
      $ eg push --branch stable 

Options
  --bypass-modification-check, -b
    To prevent you from pushing an incomplete set of changes, push
    typically checks whether you have new unknown files or modified files
    present and aborts if so.  You can bypass these checks with this
    option.

  --branch BRANCH
    Push commits in the specified branch.  May be reused multiple times to
    push commits in multiple branches.

    As an advanced option, one can use the syntax LOCAL:REMOTE for the
    branch.  For example, "--branch my_bugfix:stable" would mean to use
    the my_bugfix branch of the current repository to update the stable
    branch of the remote repository.

  --tag TAG
    Push the specified tag to the remote repository.

  --all-branches
    Push commits from all branches, including branches that do not yet exist
    in the remote repository

  --matching-branches
    Push commits from all branches that exist locally and remotely.  Note that
    this option is ignored if specific branches or tags are specified, or the
    --all-branches or --all-tags options.

  --all-tags
    Push all tags to the remote repository.

  --mirror
    Make the remote repository a mirror of the local one.  This turns on
    both --all-branches and --all-tags, but it also means that tags and
    branches that do not exist in the local repository will be deleted from
    the remote repository.

Differences from git 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'.

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