Browse files

Fixed regression with splitting out new subtree

A folder in a repository that wasn't initially imported as a  subtree could no longer be splitted into an entirely new subtree with no parent.

A fix and a new test to fix that regression is added here.
  • Loading branch information...
1 parent 448e71e commit 39f5fff0d53bcc68f5c698150d2d3b35eececc27 @voxpelli voxpelli committed May 20, 2010
Showing with 13 additions and 1 deletion.
  1. +4 −1
  2. +9 −0
@@ -253,6 +253,7 @@ find_existing_splits()
if [ -n "$main" -a -n "$sub" ]; then
debug " Prior: $main -> $sub"
cache_set $main $sub
+ cache_set $sub $sub
try_remove_previous "$main"
try_remove_previous "$sub"
@@ -569,7 +570,9 @@ cmd_split()
# ugly. is there no better way to tell if this is a subtree
# vs. a mainline commit? Does it matter?
if [ -z $tree ]; then
- cache_set $rev $rev
+ if [ -n "$newparents" ]; then
+ cache_set $rev $rev
+ fi
@@ -294,6 +294,15 @@ git subtree split --prefix subdir --branch mainsub4
# but it wasn't, because it's cache was not set to itself)
check_equal "$(git log --pretty=format:%P -1 mainsub4)" "$(git rev-parse sub3)"
+mkdir subdir2
+create subdir2/main-sub5
+git commit -m "main-sub5"
+git subtree split --prefix subdir2 --branch mainsub5
+# also test that we still can split out an entirely new subtree
+# if the parent of the first commit in the tree isn't empty,
+# then the new subtree has accidently been attached to something
+check_equal "$(git log --pretty=format:%P -1 mainsub5)" ""
# make sure no patch changes more than one file. The original set of commits

0 comments on commit 39f5fff

Please sign in to comment.