How to move files from one git repo to another preserving history using `git format-patch`and `git am`

Question

Problem

I\'d like to move a folder (and subfolder contained files) from one repository to another, preserving the history.

I found one appro

Answer 1

There's a tool for surgery like this, git filter-branch.

For something this simple, you don't need much of a safety net. For reference, though, this is how I do pretty much anything that might dirty up history or namespace or worktree

# make a throwaway sandbox to play in:
git clone -s . /tmp/deleteme
cd !$
git checkout -b sliced

# do it
git filter-branch --subdirectory-filter your/subdir

# and if the result looks good:
git push origin sliced

^{filter-branch docs}

and you can push to any repo you have a url or a path for, just use the url directly instead of making a remote name for onesy-twosie work. To push and rename: git push u://r/l sliced:branchnameinthatrepo

---

From comments you want to both select and relocate the subdirectory. That's some fairly straightforward git read-tree work. Read-tree operates on the index, so you want an index filter for it. To wit, this one:

git filter-branch --index-filter '
        git read-tree --prefix=des/ti/nation/    $GIT_COMMIT:source/subdir
        git read-tree -m                         $GIT_COMMIT    `git mktree </dev/null`
'

which despite its unfamiliarity is quite simple if you just recall how git works.

As reminder or recap or intro as the case may be:

1. The repository proper is an object store: ask for anything by type and unique name (aka SHA1), the repo obligingly regurgitates it; ask the repo to remember any content, you feed it type and bytes and it (a) stores that and (b) feeds you the unique name for it.

2. The index is just a list, mapping pathnames to the repository content that goes there.

3. git read-tree is the underlying operation for checkout and merge and reset -- it doesn't actually operate on the repo, all the objects it works with are already there. You feed it existing trees, it combines them with what's in the index (and optionally updates the worktree, though that's irrelevant here) to produce the index you want, or at least get you one step closer to it.

The first read-tree above is

    git read-tree --prefix=destination/subdir/ $GIT_COMMIT:source/subdir

and you can identify the fundamental nature of what git read-tree is going to do by counting how many trees you gave it. This one is a one-tree read, used here to add to the index (edit: btw, with no options, 1-tree git read-tree replaces the index). The tree getting added here is at source/subdir in the commit being filtered, and read-tree adds it all to the index with destination/subdir/ added to the front of the pathnames.

The next read-tree is a two-tree read, it does the index (and worktree, if there was any you wanted to do here) work for git checkout -- it applies the differences between the original tree and the target tree to the index. Here, the original tree is $GIT_COMMIT and the target tree, git mktree </dev/null, is the empty tree. So the operation is "find everything in the original tree in the index and make all those entries look exactly like the target tree" aka here "make them all go away". The added destination subdir above is not involved, it wasn't in the original tree so read-tree doesn't make that go away.

The filter's done, filter-branch commits what's in the new index (of content already in the repo, remember) and it's time for the next commit.

^{read-tree docs. This link skips the description, that's intentional. Don't read it.}

Answer 2

It looks like the problem you are having is that certain files exist in both repositories you are trying to then create them from the patch. In your example these are README.md and .gitignore

When applying the patch with git-apply, you can ignore these files with --exclude=<path-pattern>. See http://git-scm.com/docs/git-apply