threads / patch / 51009

patchFix cvsexportcommit with CR/LF line endings

Subject: [PATCH 0/1] Fix cvsexportcommit with CR/LF line endings

## tl;dr

7 messages between Apr 29, 2019 and May 8, 2019. Diffs are folded; open one to read it.

replies: 6people: 3as markdown or json

Johannes Schindelin via GitGitGadget· Apr 29, 2019, 21:58 UTC · lore

When using CVSNT, we need to be prepared to grok CVS output with CR/LF line endings.

While we do not use CVSNT in Git for Windows, this patch made its way into Git's source code via the Git for Windows project (probably because of the ease of GitHub PRs), and we had not a single complaint for over 2 years, so I would consider this patch ready to be included in core Git.

Dustin Spicuzza (1):
  cvsexportcommit: force crlf translation
 git-cvsexportcommit.perl | 1 +
 1 file changed, 1 insertion(+)
base-commit: 39ffebd23b1ef6830bf86043ef0b5c069d9299a9
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-132%2Fdscho%2Fcvsexportcommit-crlf-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-132/dscho/cvsexportcommit-crlf-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/132
-- 
gitgitgadget
Dustin Spicuzza via GitGitGadget· Apr 29, 2019, 21:58 UTC · re: Johannes Schindelin via GitGitGadget · lore

[PATCH 1/1] cvsexportcommit: force crlf translation

From: Dustin Spicuzza <dustin@virtualroadside.com>

When using cvsnt + msys + git, it seems like the output of cvs status had \r\n in it, and caused the command to fail.

This fixes that.
Signed-off-by: Dustin Spicuzza <dustin@virtualroadside.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 git-cvsexportcommit.perl | 1 +
 1 file changed, 1 insertion(+)
Show changes to git-cvsexportcommit.perl +1 −0
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d13f02da95..fc00d5946a 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -431,6 +431,7 @@ END
 sub safe_pipe_capture {
     my @output;
     if (my $pid = open my $child, '-|') {
+	binmode($child, ":crlf");
 	@output = (<$child>);
 	close $child or die join(' ',@_).": $! $?";
     } else {
-- 
gitgitgadget
Junio C Hamano· May 7, 2019, 09:22 UTC · re: Dustin Spicuzza via GitGitGadget · lore

Re: [PATCH 1/1] cvsexportcommit: force crlf translation

"Dustin Spicuzza via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Dustin Spicuzza <dustin@virtualroadside.com>
>
> When using cvsnt + msys + git, it seems like the output of cvs status
> had \r\n in it, and caused the command to fail.

This is a bit under-explained in that it does not make it clear where the right place to fix would be. From "X did Y which caused the command to fail", a possible right fix could be "so fix it by telling X not to do Y", but of course a patch to fix cvsnt won't come to this list ;-)

I haven't thought things through, so let's think it aloud and enumerate what should have been explained in the log message here.

 - With binmode(":crlf"), (i.e. if the platform uses CRLF convert
   external CRLF into internal '\n'), the change hopes not to affect
   platforms that do not use CRLF.
 - "it SEEMS LIKE the output of cvs status had CRLF in it", i.e. it
   is uncertain if everybody on the platform has the same issue.
   But by using binmode(":crlf"), if some other implementations of
   "cvs status" on the platform used LF, they won't get negatively
   affected by this change, either.

So, I guess the change is safe enough that it does not hurt other people.

Show 21 quoted lines
>
> This fixes that.
>
> Signed-off-by: Dustin Spicuzza <dustin@virtualroadside.com>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  git-cvsexportcommit.perl | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
> index d13f02da95..fc00d5946a 100755
> --- a/git-cvsexportcommit.perl
> +++ b/git-cvsexportcommit.perl
> @@ -431,6 +431,7 @@ END
>  sub safe_pipe_capture {
>      my @output;
>      if (my $pid = open my $child, '-|') {
> +	binmode($child, ":crlf");
>  	@output = (<$child>);
>  	close $child or die join(' ',@_).": $! $?";
>      } else {
Dustin Spicuzza· May 7, 2019, 13:51 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/1] cvsexportcommit: force crlf translation

Yes, your interpretation is exactly correct, even the interpretation of the uncertainty of the message.

I didn't send the patch to this list though, not sure why gitgitgadget decided to do so (I've never heard of it before now). The patch was originally submitted to git for windows (PR #938), with an even worse commit message. :)

However, I'm not opposed to it being merged elsewhere. As you pointed out, it shouldn't negatively affect non-CRLF platforms.

Dustin
On 5/7/19 5:22 AM, Junio C Hamano wrote:
Show 48 quoted lines
> "Dustin Spicuzza via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: Dustin Spicuzza <dustin@virtualroadside.com>
>>
>> When using cvsnt + msys + git, it seems like the output of cvs status
>> had \r\n in it, and caused the command to fail.
> This is a bit under-explained in that it does not make it clear
> where the right place to fix would be.  From "X did Y which caused
> the command to fail", a possible right fix could be "so fix it by
> telling X not to do Y", but of course a patch to fix cvsnt won't
> come to this list ;-)
>
> I haven't thought things through, so let's think it aloud and
> enumerate what should have been explained in the log message here.
>
>  - With binmode(":crlf"), (i.e. if the platform uses CRLF convert
>    external CRLF into internal '\n'), the change hopes not to affect
>    platforms that do not use CRLF.
>
>  - "it SEEMS LIKE the output of cvs status had CRLF in it", i.e. it
>    is uncertain if everybody on the platform has the same issue.
>    But by using binmode(":crlf"), if some other implementations of
>    "cvs status" on the platform used LF, they won't get negatively
>    affected by this change, either.
>
> So, I guess the change is safe enough that it does not hurt other
> people.
>
>> This fixes that.
>>
>> Signed-off-by: Dustin Spicuzza <dustin@virtualroadside.com>
>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>> ---
>>  git-cvsexportcommit.perl | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
>> index d13f02da95..fc00d5946a 100755
>> --- a/git-cvsexportcommit.perl
>> +++ b/git-cvsexportcommit.perl
>> @@ -431,6 +431,7 @@ END
>>  sub safe_pipe_capture {
>>      my @output;
>>      if (my $pid = open my $child, '-|') {
>> +	binmode($child, ":crlf");
>>  	@output = (<$child>);
>>  	close $child or die join(' ',@_).": $! $?";
>>      } else {
Junio C Hamano· May 7, 2019, 14:02 UTC · re: Dustin Spicuzza · lore

Re: [PATCH 1/1] cvsexportcommit: force crlf translation

Dustin Spicuzza <dustin@virtualroadside.com> writes:
Show 7 quoted lines
> Yes, your interpretation is exactly correct, even the interpretation of
> the uncertainty of the message.
>
> I didn't send the patch to this list though, not sure why gitgitgadget
> decided to do so (I've never heard of it before now). The patch was
> originally submitted to git for windows (PR #938), with an even worse
> commit message. :)

The credit goes to Dscho, making effort to slim down patches Git for Windows carries on top of my tree by upstreaming them.

Johannes Schindelin· May 8, 2019, 10:56 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/1] cvsexportcommit: force crlf translation

Hi Junio,
On Tue, 7 May 2019, Junio C Hamano wrote:
Show 12 quoted lines
> "Dustin Spicuzza via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Dustin Spicuzza <dustin@virtualroadside.com>
> >
> > When using cvsnt + msys + git, it seems like the output of cvs status
> > had \r\n in it, and caused the command to fail.
>
> This is a bit under-explained in that it does not make it clear
> where the right place to fix would be.  From "X did Y which caused
> the command to fail", a possible right fix could be "so fix it by
> telling X not to do Y", but of course a patch to fix cvsnt won't
> come to this list ;-)
Right.
How about this:
	The offical CVS for Windows (called CVS NT) produces DOS line
	endings in its `cvs status` output. Let's teach our own
	`cvsexportcommit` command to handle that gracefully.

It is unlikely that anybody wants to spend time "fixing" this in CVS NT, even less likely that anybody would take that patch, and even if that was the case, there will still be plenty of CVS NT versions out there that `cvsexportcommit` cannot handle.

I think it would be best to just integrate this change in Git and be done with it. It's not like it adds a ton of maintenance burden there.

(BTW this was also my thinking when I accepted that patch into Git for Windows, and thereby accepted the responsibility of upstreaming it.)

Ciao, Dscho

Junio C Hamano· May 8, 2019, 10:59 UTC · re: Johannes Schindelin · lore

Re: [PATCH 1/1] cvsexportcommit: force crlf translation

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 13 quoted lines
> How about this:
>
> 	The offical CVS for Windows (called CVS NT) produces DOS line
> 	endings in its `cvs status` output. Let's teach our own
> 	`cvsexportcommit` command to handle that gracefully.
>
> It is unlikely that anybody wants to spend time "fixing" this in CVS NT,
> even less likely that anybody would take that patch, and even if that was
> the case, there will still be plenty of CVS NT versions out there that
> `cvsexportcommit` cannot handle.
>
> I think it would be best to just integrate this change in Git and be done
> with it. It's not like it adds a ton of maintenance burden there.

One thing that took some time (at least to me) to audit was that the helper being touched is *NOT* limited to running "cvs status". If other commands cared about passing binary data intact, this change would have been disasterous. After seeing what external commands it is told to drive, I think it is OK. It's not like we'd be updating the program often and reusing the function blindly to accept possibly binary data in a near future.

← back to recent threads