On 20 July 2017 at 02:54, Tillson Galloway <tillson.gallo...@gmail.com> wrote:
> Context:
> We currently have a git project with a root directory ("~/project")
> for pipelines and deployment of a Node app, and then a subdirectory
> ("~/project/project-app").
> After realizing that we didn't need the node app in a subdirectory, we
> moved the full app into the root directory (using the mv command).
>
[...]
>
> Running "git status" shows that git successfully tracked that the
> original files within ~/project/project-app were deleted, but it did
> not pick up the "newly created" files from moving.
So you did "mv project-app/* ." and see something like
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: ... lots of files ...
? That means Git has *realized* that the files are gone, but it's not
*tracking* that fact (yet).
What if you restore the files and instead try "git mv project-app/*
."? It will move the files like "mv", but it will also do basically
what you wanted to achieve with "git add --all". After that, you'll
just have to "git commit".
You'll probably want to "rmdir project-app/" once it's empty. If you
have some structure like project-app/project-app/ the move might fail
(should be possible to work around).
This obviously doesn't address the problem you saw and on which I
cannot comment, but I hope it helps you do what you actually wanted to
do. :)
Martin
