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?

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to