[PATCH 0/2] git subtree: properly handle remote refs

One common use-case for git subtree is to use it only on taged commits from the remote project. however the current implementation of gi-subtree can not be used in that way. two orthogonal prevent this

the SHA used as the origin revision can be the SHA of a tag which isn't available locally. This works correctly at merge time but will fail at split time. The first patch uses the ^{} notation to make sure a correct commit SHA is used instead of the SHA given as a parameter

the checks for the correctness of the target ref to pull or add checks that the name matches a local ref (which is incorrect). The second patch use ls-remote to validate the ref name given against the ones in the remote repository

Jérémy Rosen (2):
  git-subtree: make sure the SHA saved as ancestor is a commit
  git-subtree: use ls-remote to check the refspec passed to pull and
    add

 contrib/subtree/git-subtree.sh |   15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

-- 
1.7.10.4

When adding or merging the first parameter might not be a commit, it can also be a tag SHA.
This needs to be fixed by using the underlying commit or the ancestor finding code will croak at split time


Signed-off-by: Jérémy Rosen <redacted>
---
 contrib/subtree/git-subtree.sh |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8a23f58..8b9d114 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh

@@ -531,7 +531,7 @@ cmd_add_repository()
 
 cmd_add_commit()
 {
-	revs=$(git rev-parse $default --revs-only "$@") || exit $?
+	revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit $?
 	set -- $revs
 	rev="$1"
 	

@@ -655,7 +655,7 @@ cmd_split()
 
 cmd_merge()
 {
-	revs=$(git rev-parse $default --revs-only "$@") || exit $?
+	revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit $?
 	ensure_clean
 	
 	set -- $revs

-- 
1.7.10.4

ls-remote is the correct way to check that a parameter is a valid fetchable target


Signed-off-by: Jérémy Rosen <redacted>
---
 contrib/subtree/git-subtree.sh |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8b9d114..61d4eab 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh

@@ -503,13 +503,8 @@ cmd_add()
 
 	    "cmd_add_commit" "$@"
 	elif [ $# -eq 2 ]; then
-	    # Technically we could accept a refspec here but we're
-	    # just going to turn around and add FETCH_HEAD under the
-	    # specified directory.  Allowing a refspec might be
-	    # misleading because we won't do anything with any other
-	    # branches fetched via the refspec.
-	    git rev-parse -q --verify "$2^{commit}" >/dev/null ||
-	    die "'$2' does not refer to a commit"
+		git ls-remote --exit-code "$1" "$2" ||
+		die "'$2' is not a correct reference on '$1'"
 
 	    "cmd_add_repository" "$@"
 	else

@@ -700,6 +695,8 @@ cmd_merge()
 cmd_pull()
 {
 	ensure_clean
+	git ls-remote --exit-code "$1" "$2" ||
+		die "'$2' is not a correct reference on '$1'"
 	git fetch "$@" || exit $?
 	revs=FETCH_HEAD
 	set -- $revs

-- 
1.7.10.4