push: Push local commits to a published repository
eg push [--bypass-modification-check] [--branch BRANCH] [--tag TAG]
[--all-branches] [--all-tags] [--mirror] REPOSITORY
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'.
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://firstname.lastname@example.org: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
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
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.
Push the specified tag to the remote repository.
Push commits from all branches, including branches that do not yet exist
in the remote repository
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.
Push all tags to the remote repository.
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'.
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