On Thu, Oct 31, 2013 at 1:47 PM, Max Horn <[email protected]> wrote: > > On 31.10.2013, at 20:41, Felipe Contreras <[email protected]> wrote: > >> On Thu, Oct 31, 2013 at 1:29 PM, Max Horn <[email protected]> wrote: >>> Actually, I just noticed one thing that I *do* have a question about: >>> >>> On 31.10.2013, at 10:36, Felipe Contreras <[email protected]> >>> wrote: >>> >>>> Signed-off-by: Felipe Contreras <[email protected]> >>>> --- >>>> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
