"Marco Costalba" <mcostalba@xxxxxxxxx> writes:
> On 5/21/07, Junio C Hamano <junkio@xxxxxxx> wrote:
>> Junio C Hamano <junkio@xxxxxxx> writes:
>>
>>
>> We somehow end up removing one LF too many, like this:
>>
>> diff --git a/contrib/emacs/.gitignore b/contrib/emacs/.gitignore
>> index c531d98..016d3b1 100644
>> --- a/contrib/emacs/.gitignore
>> +++ b/contrib/emacs/.gitignore
>> @@ -1 +1 @@
>> -*.elc
>> +*.elc
>> \ No newline at end of file
>>
>
> I also had that, but after adding
>
> +
> + if (empty < trailing_added_lines)
> + empty--;
> +
>
> everything worked correctly. I made again the same test myself
> without problems.
>
> I really don't understand how could be broken.
Hmmm. Puzzled.
Let's say that the patch is to create a file that has a single
line, like this:
diff --git a/contrib/emacs/.gitignore b/contrib/emacs/.gitignore
new file mode 100644
index 0000000..c531d98
--- /dev/null
+++ b/contrib/emacs/.gitignore
@@ -0,0 +1 @@
+*.elc
The function "apply_one_fragment" gets two lines ('@' and '+').
We come to "while (size > 0)" loop. During the first round,
'first' is '@' and the line is ignored. In the second round,
'first' is '+', so apply_line appends the contents to 'new'
buffer, while we count trailing_added_lines.
End result is
- newsize = 6, new has "*.elc\n";
- oldsize = 0, and old has "";
- trailing_added_lines = 1;
when we get to the "empty" counting code.
Then you count empty up to trailing_added_lines. When we get to
the "if (empty < trailing_added_lines)" code, empty is 1. You
do not decrement this, and take that number in
trailing_added_lines, to be used to strip the trailing run of
newlines in the for (;;) loop later. That's how you can lose
the last newline that is not on a blank line.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
