patch, 2 partsfast-import: add special mode; copy from parent.

> @@ -1862,7 +1864,7 @@ static void file_change_m(struct branch *b)
>  	const char *endp;
>  	struct object_entry *oe = oe;
>  	unsigned char sha1[20];
> -	uint16_t mode, inline_data = 0;
> +	uint16_t mode, inline_data = 0, empty_blob = 0;

> @@ -1893,6 +1895,10 @@ static void file_change_m(struct branch *b)
>  	} else if (!prefixcmp(p, "inline")) {
>  		inline_data = 1;
>  		p += 6;
> +	} else if (!prefixcmp(p, "- ")) {
> +		hashclr(sha1);
> +		empty_blob = 1;
> +		p += 1;

> Hmph, so if create a new path with a blob of "-" the repository
> will be corrupt because the zero id was used and error was produced.
>
> Actually I think you have the same bug in the prior patch with the
> mode being inherited.  I wonder if we shouldn't put error checking
> in too to validate that versions[0] describes a file entry.

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Hmph, so if create a new path with a blob of "-" the repository
> > will be corrupt because the zero id was used and error was produced.
> >
> > Actually I think you have the same bug in the prior patch with the
> > mode being inherited.  I wonder if we shouldn't put error checking
> > in too to validate that versions[0] describes a file entry.
> 
> Why are these patches necessary?
> 
> The proposed commit message describes what it does, but does not give hint
> to even guess being able to use this new feature helps in what situation.
> As far as I can see, these changes allow the exporter to say "this aspect
> of the new data is the same as the previous one", but I thought that the
> way in which fast-import works already revolves around "you have this
> tree, and the next tree is different from it in this and that way."  Why
> does one need be able to mention "this is the same as the previous one"
> explicitly in the first place?

> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>
>> > Hmph, so if create a new path with a blob of "-" the repository
>> > will be corrupt because the zero id was used and error was produced.
>> >
>> > Actually I think you have the same bug in the prior patch with the
>> > mode being inherited.  I wonder if we shouldn't put error checking
>> > in too to validate that versions[0] describes a file entry.
>>
>> Why are these patches necessary?

>> The proposed commit message describes what it does, but does not give hint
>> to even guess being able to use this new feature helps in what situation.
>> As far as I can see, these changes allow the exporter to say "this aspect
>> of the new data is the same as the previous one", but I thought that the
>> way in which fast-import works already revolves around "you have this
>> tree, and the next tree is different from it in this and that way."  Why
>> does one need be able to mention "this is the same as the previous one"
>> explicitly in the first place?
>
> Hmm.  Actually, imagine you were dumping from git-diff output style
> stream into a fast-import stream.
>
> If a file changes only content, the mode is shown in the index line.
> Yay us.  But what if the index line wasn't present in the diff? You
> don't know the prior mode of the file, but you do have its content.
>
> If a file changes only mode, we get no content hints in the diff.
> How do you send that into fast-import without making the frontend
> keep track of every path's current mode?
>
> Though I agree, these details should be described in the commit
> messages, not left as an exercise for the maintainer to make up.

> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> @@ -1862,7 +1864,7 @@ static void file_change_m(struct branch *b)
>>       const char *endp;
>>       struct object_entry *oe = oe;
>>       unsigned char sha1[20];
>> -     uint16_t mode, inline_data = 0;
>> +     uint16_t mode, inline_data = 0, empty_blob = 0;
>
> Its not the empty blob, its the inherited/assumed blob...

>> @@ -1893,6 +1895,10 @@ static void file_change_m(struct branch *b)
>>       } else if (!prefixcmp(p, "inline")) {
>>               inline_data = 1;
>>               p += 6;
>> +     } else if (!prefixcmp(p, "- ")) {
>> +             hashclr(sha1);
>> +             empty_blob = 1;
>> +             p += 1;
>
> Hmph, so if create a new path with a blob of "-" the repository
> will be corrupt because the zero id was used and error was produced.
>
> Actually I think you have the same bug in the prior patch with the
> mode being inherited.  I wonder if we shouldn't put error checking
> in too to validate that versions[0] describes a file entry.

> +	} else {
> +		p = get_mode(p, &mode);
> +		if (!p)
> +			die("Corrupt mode: %s", command_buf.buf);
> +		switch (mode) {
> +		case S_IFREG | 0644:
> +		case S_IFREG | 0755:
> +		case S_IFLNK:
> +		case S_IFGITLINK:
> +		case 0644:
> +		case 0755:
> +			/* ok */
> +			break;
> +		default:
> +			die("Corrupt mode: %s", command_buf.buf);
> +		}

> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> +     if (!prefixcmp(p, "- ")) {
>> +             mode = 0;
>> +             p += 2;
>
> This part made me wonder, why are we always doing "S_IFREG | mode"
> further down?

> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  Documentation/git-fast-import.txt |    1 +
>  fast-import.c                     |   41 +++++++++++++++++++++---------------
>  2 files changed, 25 insertions(+), 17 deletions(-)