mirror of
https://github.com/git/git
synced 2024-07-16 10:38:05 +00:00
23a9235d52
It's arguably more correct to say "[<option>...]" than either of these forms, but the vast majority of our documentation uses the "[<options>]" form to indicate an arbitrary number of options, let's do the same in these cases, which were the odd ones out. In the case of "mv" and "sparse-checkout" let's add the missing "[]" to indicate that these are optional. In the case of "t/helper/test-proc-receive.c" there is no *.txt version, making it the only hunk in this commit that's not a "doc txt & -h consistency" change. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
70 lines
2 KiB
Plaintext
70 lines
2 KiB
Plaintext
git-mv(1)
|
|
=========
|
|
|
|
NAME
|
|
----
|
|
git-mv - Move or rename a file, a directory, or a symlink
|
|
|
|
|
|
SYNOPSIS
|
|
--------
|
|
[verse]
|
|
'git mv' [<options>] <args>...
|
|
|
|
DESCRIPTION
|
|
-----------
|
|
Move or rename a file, directory or symlink.
|
|
|
|
git mv [-v] [-f] [-n] [-k] <source> <destination>
|
|
git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>
|
|
|
|
In the first form, it renames <source>, which must exist and be either
|
|
a file, symlink or directory, to <destination>.
|
|
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::
|
|
--force::
|
|
Force renaming or moving of a file even if the target exists
|
|
-k::
|
|
Skip move or rename actions which would lead to an error
|
|
condition. An error happens when a source is neither existing nor
|
|
controlled by Git, or when it would overwrite an existing
|
|
file unless `-f` is given.
|
|
-n::
|
|
--dry-run::
|
|
Do nothing; only show what would happen
|
|
|
|
-v::
|
|
--verbose::
|
|
Report the names of files as they are moved.
|
|
|
|
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.
|
|
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).
|
|
|
|
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.
|
|
|
|
GIT
|
|
---
|
|
Part of the linkgit:git[1] suite
|