Why are these subtree assertions failing?

Question

I am attempting to use git subtree to split my repository into multiple repositories while maintaining all history. In this case, I am trying to split individual files out of a main repository into their own repositories so they can be maintained as independent projects.

I tried to run the command

git subtree split -P lib/a.lua -b temp

but got the following output:

assertion failed:  test blob = tree -o blob = commit
assertion failed:  test blob = tree -o blob = commit
assertion failed:  test blob = tree -o blob = commit
…

What does this mean? What am I doing wrong? My directory looks like this:

project
 ├ main.lua
 └ lib
    ├ a.lua
    └ b.lua

Answer 1

It seems, @nethergranite figured it out. Git's git-subtree may not be able to track individual files for git-subtree --split, at least in some present versions.

I've discovered a similar error from git-subtree when trying to recover some deleted code from the GNU Emacs 'lisp/obsolete' directory – namely, one scribe.el. When I ran git-subtree -P <file-pathname> [other-args] Git similarly began emitting the assertion failed mesage.

Alternately, using the syntax e.g

git subtree split -b split_${changest_ID} --annotate="split lisp/obsolete:" -P lisp/obsolete/

... then it runs just fine, using the relative directory as a prefix for git-subtree(1)

For admin purposes, the changest_ID can be retrieved with e.g

git log --pretty=short --abbrev-commit -n1 -- relpath/to/subdir/

...futhermore, parsing for the commit refererence (ID) with text tools e.g

git log --pretty=short --abbrev-commit -n1 -- relpath/to/subdir/ | head -n1 | awk '{print $2}'

The derived branch name -- split_${changest_ID} -- can then be used to push the directory's subtree to a local, bare git repository, from which it can then be managed independent of the original source tree … license/linkage/redist stipulations permitting. Further documentation may be available in the git-subtree(1) manual page.

Beside all that, it seems git-subtree may simply need a directory prefix, rather than an individual file as prefix -- pending any revisions to its source code as such, if git-subtree ever may theoretically create a subtree from a single file prefix, insofar as how git manages its internal state in a Git repository.