2005-10-23 16:15:34 +00:00
|
|
|
git-mv(1)
|
|
|
|
=========
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
2007-01-18 23:53:37 +00:00
|
|
|
git-mv - Move or rename a file, a directory, or a symlink
|
2005-10-23 16:15:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
2011-07-02 02:38:26 +00:00
|
|
|
[verse]
|
2008-06-30 06:09:04 +00:00
|
|
|
'git mv' <options>... <args>...
|
2005-10-23 16:15:34 +00:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
2013-07-30 19:50:03 +00:00
|
|
|
Move or rename a file, directory or symlink.
|
2005-12-05 08:15:44 +00:00
|
|
|
|
2011-12-12 07:51:24 +00:00
|
|
|
git mv [-v] [-f] [-n] [-k] <source> <destination>
|
|
|
|
git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>
|
2005-12-05 08:15:44 +00:00
|
|
|
|
2005-10-23 16:15:34 +00:00
|
|
|
In the first form, it renames <source>, which must exist and be either
|
2005-11-27 21:08:33 +00:00
|
|
|
a file, symlink or directory, to <destination>.
|
2005-10-23 16:15:34 +00:00
|
|
|
In the second form, the last argument has to be an existing
|
|
|
|
directory; the given sources will be moved into this directory.
|
|
|
|
|
|
|
|
The index is updated after successful completion, but the change must still be
|
|
|
|
committed.
|
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
-------
|
|
|
|
-f::
|
2009-08-29 09:05:00 +00:00
|
|
|
--force::
|
2005-11-27 21:08:33 +00:00
|
|
|
Force renaming or moving of a file even if the target exists
|
2005-10-23 16:15:34 +00:00
|
|
|
-k::
|
2016-06-28 11:40:09 +00:00
|
|
|
Skip move or rename actions which would lead to an error
|
2005-10-23 16:15:34 +00:00
|
|
|
condition. An error happens when a source is neither existing nor
|
2013-01-21 19:16:20 +00:00
|
|
|
controlled by Git, or when it would overwrite an existing
|
2016-06-28 11:40:10 +00:00
|
|
|
file unless `-f` is given.
|
2008-06-08 01:36:09 +00:00
|
|
|
-n::
|
|
|
|
--dry-run::
|
2005-10-23 16:15:34 +00:00
|
|
|
Do nothing; only show what would happen
|
|
|
|
|
2011-12-12 07:51:24 +00:00
|
|
|
-v::
|
|
|
|
--verbose::
|
|
|
|
Report the names of files as they are moved.
|
|
|
|
|
2013-07-30 19:50:03 +00:00
|
|
|
SUBMODULES
|
|
|
|
----------
|
|
|
|
Moving a submodule using a gitfile (which means they were cloned
|
|
|
|
with a Git version 1.7.8 or newer) will update the gitfile and
|
|
|
|
core.worktree setting to make the submodule work in the new location.
|
2013-08-06 19:15:11 +00:00
|
|
|
It also will attempt to update the submodule.<name>.path setting in
|
|
|
|
the linkgit:gitmodules[5] file and stage that file (unless -n is used).
|
2013-07-30 19:50:03 +00:00
|
|
|
|
2014-01-07 21:31:32 +00:00
|
|
|
BUGS
|
|
|
|
----
|
|
|
|
Each time a superproject update moves a populated submodule (e.g. when
|
|
|
|
switching between commits before and after the move) a stale submodule
|
|
|
|
checkout will remain in the old location and an empty directory will
|
|
|
|
appear in the new location. To populate the submodule again in the new
|
|
|
|
location the user will have to run "git submodule update"
|
|
|
|
afterwards. Removing the old directory is only safe when it uses a
|
|
|
|
gitfile, as otherwise the history of the submodule will be deleted
|
|
|
|
too. Both steps will be obsolete when recursive submodule update has
|
|
|
|
been implemented.
|
|
|
|
|
2005-10-23 16:15:34 +00:00
|
|
|
GIT
|
|
|
|
---
|
2008-06-06 07:07:32 +00:00
|
|
|
Part of the linkgit:git[1] suite
|