How does one move the contents of a directory or a single file to another directory?
I did the following git mv Jarryd/movementcommands.c src
and got this fatal: not under version control, source=Jarryd/movementcommands.c, destination=src/movementcommands.c
How should it be moved?
like this git mv Jarryd/movementcommands.c src/movementcommands.c ?
Both forms should work but because your source file isn't under git's control you don't need git mv, a simple move and add is needed. (I assume that both Jarryd and src are in your git working tree.)
mv Jarryd/movementcommands.c src git add src/movementcommands.c Are you sure that Jarryd/movementcommands.c file or src folder are tracked by git?
Anyway you can try just
mv Jarryd/movementcommands.c src
git add src/movementcommands.c Ensure that both the source and destination directories are under git version control, like the error message says.
Also, this probably won't work if you're trying to move something out of a git submodule. I don't think git is designed to track that. (If you don't know what this paragraph means, it doesn't apply to you.)
Note that before With Git 2.29 (Q4 2020), "git mv src dst(man), when src is an unmerged path, errored out correctly but with an incorrect error message to claim that src is not tracked.
Meaning fatal: not under version control did not always means "untracked".
See commit 9b906af (20 Jul 2020) by Chris Torek (chris3torek).
(Merged by Junio C Hamano -- gitster -- in commit be2dab9, 30 Jul 2020)
git-mv: improve error message for conflicted fileSigned-off-by: Chris Torek
'
git mv(man) ' has always complained about renaming a conflicted file, as it cannot handle multiple index entries for one file. However, the error message it uses has been the same as the one for an untracked file:fatal: not under version control, src=...which is patently wrong.
Distinguish the two cases and add a test to make sure we produce the correct message.
Then new error message, in case you are moving a file with conflict during a merge/rebase, will be:
fatal: conflicted which is better than:
fatal: not under version control However...
Git 2.31.1 (Q1 2021) fixes a corner case bug in "git mv"(man) on case insensitive systems, which was introduced in 2.29 timeframe.
Example of 2.29/2.30/2.31 issue:
c:\git_CAP\repo_MFW2>git mv mfw2/application/phaseCalc_IQ_Xiong.hpp PC_phaseTest/phaseCalc_IQ_Xiong.hpp Assertion failed: pos >= 0, file builtin/mv.c, line 295 See commit 93c3d29 (01 Mar 2021) by Torsten Bögershausen (tboegi).
(Merged by Junio C Hamano -- gitster -- in commit ef486a9, 19 Mar 2021)
93c3d297b5:git mv foo FOO;git mv foo bargave an assertReported-By: Dan Moseley
Signed-off-by: Torsten Bögershausen
The following sequence, on a case-insensitive file system, (strictly speeking with
core.ignorecase=true) leads to an assertion failure and leaves.git/index.lockbehind.
git init(man) echo foo >foogit add(man) foogit mv(man) foo FOOgit mvfoo barThis regression was introduced in commit 9b906af (
git-mv: improve error message for conflicted file, 2020-07-20, Git v2.29.0-rc0 -- merge listed in batch #1).The bugfix is to change the "file exist case-insensitive in the index" into the correct "file exist (case-sensitive) in the index".
This avoids the "assert" later in the code and keeps setting up the "
ce" pointer force_stage(ce)done in the next else if.This fixes
git-for-windows/gitissue 2920
