Paul, I'm not quite sure where I should go from here...
should I send you a patch so you make it a V3 of your patch ? should I
send a patch superseeding yours ?
I have also found a similar problem in git-subtree pull, which needs
the same fix.
in the mean time, attached is the current version of my changes
Cordialement
Jérémy Rosen
fight key loggers : write some perl using vim
From 12490724ae955719694d825dff4fa9e0d2709c1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?= <jeremy.rosen@xxxxxxxxxxx>
Date: Tue, 12 Mar 2013 10:56:54 +0100
Subject: [PATCH 1/2] git-subtree: make sure the SHA saved as ancestor is a
commit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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 <jeremy.rosen@xxxxxxxxxxx>
---
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
From 05d1dd56217be59d69952a41d97e204cc7821948 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?= <jeremy.rosen@xxxxxxxxxxx>
Date: Tue, 12 Mar 2013 10:57:56 +0100
Subject: [PATCH 2/2] git-subtree: use ls-remote to check the refspec passed
to pull and add
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
ls-remote is the correct way to check that a parameter is a valid fetchable target
Signed-off-by: Jérémy Rosen <jeremy.rosen@xxxxxxxxxxx>
---
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