Move file and directory into a sub-directory along with commit history

How can I move a directory and files to a sub-directory along with commit history?

For example:

• Source directory structure: [project]/x/[files & sub-dirs]

• Target directory structure: [project]/x/p/q/[files & sub-dirs]

To add to bmargulies's comment, the complete sequence is:

mkdir -p x/p/q      # make sure the parent directories exist first
git mv x/* x/p/q    # move folder, with history preserved
git commit -m "changed the foldername x into x/p/q"

Try it first to see a preview of the move:

git mv -n x/* x/p/q

---

Wolfgang comments:

> If you're using bash, you can avoid the issue of trying to move a folder into itself by using an extended glob like so (using the shopt built-in):

shopt -s extglob; git mv !(folder) folder

---

Captain Man reports in the comments having to do:

mkdir temp 
git mv x/* temp
mkdir -p x/p/q
git mv temp x/p/q
rmdir temp;

Context:

> I am on Windows with Cygwin.
I just realized I did the shopt -s extglob example wrong so my way may not have be necessary, but I typically do use zsh instead of bash, and it didn't have the command shopt -s extglob (though I'm sure there is an alternative), so this approach should work across shells (subbing in your shell's mkdir and rmdir if it's especially foreign)

---

As an alternative, spanky mentions in the comments the -k option of git mv:

> Skip move or rename actions which would lead to an error condition.

git mv -k * target/

That would avoid the "can not move directory into itself" error.

Git does a very good job to track content even if it is moved around, so git mv is clearly the way to go if you move files because they used to belong in x, but now they belong in x/p/q because the project evolved that way.

Sometimes, however, there is a reason to move files to a subdirectory throughout the history of a project. For example if the files have been put somewhere by mistake and some more commits have been made since, but the intermittent commits don't even make sense with the files in the wrong place. If all that happened on a local branch, we want to clean up the mess before pushing.

The question states "along with commit history", which I would interpret as rewriting the history in exactly that way. This can be done with

git filter-branch --tree-filter "cd x; mkdir -p p/q; mv [files & sub-dirs] p/q" HEAD

The files then appear in the p/q subdirectory throughout the history.

The tree filter is well suited for small projects, its advantage is that the command is simple and easy to understand. For large projects this solution does not scale very well, if performance matters then consider to use an index filter as outlined in this answer.

Please note that the result should not be pushed to a public server if the rewrite touches commits which were already pushed before.

I can see this is an old question, but I still feel obliged to answer With my current solution to the problem, that I have derived from one of the examples in the git book. In stead of using an inefficient --tree-filter I move the files directly on the index With an --index-filter.

git filter-branch -f --index-filter 'PATHS=`git ls-files -s | sed "s/^<old_location>/<new_location>/"`;GIT_INDEX_FILE=$GIT_INDEX_FILE.new; echo -n "$PATHS" | git update-index --index-info && if [ -e "$GIT_INDEX_FILE.new" ]; then mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"; fi' -- --all

this is a specialization of one of the examples from the book I've also used the same example to mass rename files in the commit history in one special case. if moving files in subdirectories: remember to escape the / character in the paths With a \ to make the sed command work as expected.

Example:

Project Directory
                 |-a
                 |  |-a1.txt
                 |  |-b
                 |  |  |-b1.txt

to move the b directory to the project root:

git filter-branch -f --index-filter 'PATHS=`git ls-files -s | sed "s/a\/b\//b\//"`;GIT_INDEX_FILE=$GIT_INDEX_FILE.new; echo -n "$PATHS" | git update-index --index-info && if [ -e "$GIT_INDEX_FILE.new" ]; then mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"; fi' -- --all

Result:

Project Directory
                 |-a
                 |  |-a1.txt
                 |
                 |-b
                 |  |-b1.txt

The git mv command is the simplest way. However, at least on my Linux box, I needed to supply the -k flag to avoid getting an error back that a folder cannot be moved into itself. I was able to perform the action by using...

mkdir subdirectory
git mv -k ./* ./subdirectory
# check to make sure everything moved (see below)
git commit

As a warning, this will skip all moves which would lead to an error condition, so you will probably want to check that everything worked properly after the move and before a commit.

Here is an alternative way if you for some reason do not want to use the git mv command:

• Make sure you do not have any uncommitted changes.

  git status

• Just move the folder that contains the .git folder to the new folder:

  mkdir new_folder mv old_folder new_folder

• Then move the .git old_folder from the moved folder back to the base folder:

  mv new_folder/old_folder/.git new_folder/

• Then stage and commit all the changes detected (listed as adding files to their new location and removing them from their old location)

My own suggestion: git fast-export then edit the export file, then git fast-import.