Re: [PATCH v5 09/10] fast-export: add support to delete refs
Actually, I just noticed one thing that I *do* have a question about:
On 31.10.2013, at 10:36, Felipe Contreras felipe.contre...@gmail.com wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/fast-export.c | 14 ++
t/t9350-fast-export.sh | 11 +++
2 files changed, 25 insertions(+)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index b6f623e..8ed41b4 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -673,6 +673,19 @@ static void import_marks(char *input_file)
fclose(f);
}
+static void handle_deletes(void)
+{
+ int i;
+ for (i = 0; i refspecs_nr; i++) {
+ struct refspec *refspec = refspecs[i];
+ if (*refspec-src)
+ continue;
+
+ printf(reset %s\nfrom %s\n\n,
+ refspec-dst, sha1_to_hex(null_sha1));
If I understand it right, this issues a reset command in the fast-import
stream, resetting a ref to an all-zero SHA1. I had a look at the
git-fast-import documentation, but I found that it does not explicitly cover
this case. In particular, the reset command does not specify that an all-zero
SHA1 should be treated as delete this ref. On the other hand, the docs for
reset seem to indicate that one can omit the from part, although I couldn't
tell for sure what that would mean, either.
I have not yet tried to dive into the code to figure out what actually happens,
but I assume Felipe did that resp. tested it, and so supposedly doing this
works, at least for git resp. existing transport helpers. But I wonder if other
implementers of the fast-import format would handle it properly?
In any case, it seems to me that this is a gap in the documentation, isn't it?
Or am I just being dense?
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PATCH v5 09/10] fast-export: add support to delete refs
On Thu, Oct 31, 2013 at 1:29 PM, Max Horn m...@quendi.de wrote:
Actually, I just noticed one thing that I *do* have a question about:
On 31.10.2013, at 10:36, Felipe Contreras felipe.contre...@gmail.com wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/fast-export.c | 14 ++
t/t9350-fast-export.sh | 11 +++
2 files changed, 25 insertions(+)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index b6f623e..8ed41b4 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -673,6 +673,19 @@ static void import_marks(char *input_file)
fclose(f);
}
+static void handle_deletes(void)
+{
+ int i;
+ for (i = 0; i refspecs_nr; i++) {
+ struct refspec *refspec = refspecs[i];
+ if (*refspec-src)
+ continue;
+
+ printf(reset %s\nfrom %s\n\n,
+ refspec-dst, sha1_to_hex(null_sha1));
If I understand it right, this issues a reset command in the fast-import
stream, resetting a ref to an all-zero SHA1. I had a look at the
git-fast-import documentation, but I found that it does not explicitly cover
this case. In particular, the reset command does not specify that an
all-zero SHA1 should be treated as delete this ref.
That's what the previous patch does.
On the other hand, the docs for reset seem to indicate that one can omit
the from part, although I couldn't tell for sure what that would mean,
either.
It means something different.
I have not yet tried to dive into the code to figure out what actually
happens, but I assume Felipe did that resp. tested it, and so supposedly
doing this works, at least for git resp. existing transport helpers. But I
wonder if other implementers of the fast-import format would handle it
properly?
Try this:
--- a/t/t9350-fast-export.sh
+++ b/t/t9350-fast-export.sh
@@ -519,7 +519,9 @@ test_expect_success 'delete refspec' '
from
EOF
- test_cmp expected actual
+ test_cmp expected actual
+ git fast-import actual
+ test_must_fail git rev-parse -q --verify refs/heads/to-delete
'
test_done
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 09/10] fast-export: add support to delete refs
On 31.10.2013, at 20:41, Felipe Contreras felipe.contre...@gmail.com wrote:
On Thu, Oct 31, 2013 at 1:29 PM, Max Horn m...@quendi.de wrote:
Actually, I just noticed one thing that I *do* have a question about:
On 31.10.2013, at 10:36, Felipe Contreras felipe.contre...@gmail.com wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/fast-export.c | 14 ++
t/t9350-fast-export.sh | 11 +++
2 files changed, 25 insertions(+)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index b6f623e..8ed41b4 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -673,6 +673,19 @@ static void import_marks(char *input_file)
fclose(f);
}
+static void handle_deletes(void)
+{
+ int i;
+ for (i = 0; i refspecs_nr; i++) {
+ struct refspec *refspec = refspecs[i];
+ if (*refspec-src)
+ continue;
+
+ printf(reset %s\nfrom %s\n\n,
+ refspec-dst, sha1_to_hex(null_sha1));
If I understand it right, this issues a reset command in the fast-import
stream, resetting a ref to an all-zero SHA1. I had a look at the
git-fast-import documentation, but I found that it does not explicitly cover
this case. In particular, the reset command does not specify that an
all-zero SHA1 should be treated as delete this ref.
That's what the previous patch does.
Right *facepalm*.
But then this should be documented in git-fast-import.txt, shouldn't it?
On the other hand, the docs for reset seem to indicate that one can omit
the from part, although I couldn't tell for sure what that would mean,
either.
It means something different.
Yeah, I figured that -- just wanted to point out that this, too, is not very
clear in the documentation and should be improved (not saying that I expect you
to do that, just pointing it out).
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PATCH v5 09/10] fast-export: add support to delete refs
On Thu, Oct 31, 2013 at 1:47 PM, Max Horn m...@quendi.de wrote:
On 31.10.2013, at 20:41, Felipe Contreras felipe.contre...@gmail.com wrote:
On Thu, Oct 31, 2013 at 1:29 PM, Max Horn m...@quendi.de wrote:
Actually, I just noticed one thing that I *do* have a question about:
On 31.10.2013, at 10:36, Felipe Contreras felipe.contre...@gmail.com
wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/fast-export.c | 14 ++
t/t9350-fast-export.sh | 11 +++
2 files changed, 25 insertions(+)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index b6f623e..8ed41b4 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -673,6 +673,19 @@ static void import_marks(char *input_file)
fclose(f);
}
+static void handle_deletes(void)
+{
+ int i;
+ for (i = 0; i refspecs_nr; i++) {
+ struct refspec *refspec = refspecs[i];
+ if (*refspec-src)
+ continue;
+
+ printf(reset %s\nfrom %s\n\n,
+ refspec-dst, sha1_to_hex(null_sha1));
If I understand it right, this issues a reset command in the fast-import
stream, resetting a ref to an all-zero SHA1. I had a look at the
git-fast-import documentation, but I found that it does not explicitly
cover this case. In particular, the reset command does not specify that
an all-zero SHA1 should be treated as delete this ref.
That's what the previous patch does.
Right *facepalm*.
But then this should be documented in git-fast-import.txt, shouldn't it?
It is... in the previous patch.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 09/10] fast-export: add support to delete refs
On 31.10.2013, at 20:53, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, Oct 31, 2013 at 1:47 PM, Max Horn m...@quendi.de wrote: On 31.10.2013, at 20:41, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, Oct 31, 2013 at 1:29 PM, Max Horn m...@quendi.de wrote: [...] That's what the previous patch does. Right *facepalm*. But then this should be documented in git-fast-import.txt, shouldn't it? It is... in the previous patch. Indeed, there it is. So that answer to my initial question is: Yes, I am being dense :-). So, I am (still) happy with the patch series :-) signature.asc Description: Message signed with OpenPGP using GPGMail
