undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed regression with splitting out new subtree

Browse Source 
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.
This commit is contained in:
Pelle Wessman 2010-05-20 22:40:09 +02:00
parent 448e71e263
commit 39f5fff0d5
2 changed files with 13 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
git-subtree.sh
View File

@ -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"
fi
@ -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
continue
fi

9
test.sh
View File

@ -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