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

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

[Johannes Schindelin via GitGitGadget]

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

[PATCH 1/1] cvsexportcommit: force crlf translation

[Dustin Spicuzza via GitGitGadget]

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(+)

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

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

[Junio C Hamano]

"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 {

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

[Dustin Spicuzza]

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:
> "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 {

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

[Junio C Hamano]

Dustin Spicuzza <dustin@virtualroadside.com> writes:

> 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.

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

[Johannes Schindelin]

Hi Junio,

On Tue, 7 May 2019, Junio C Hamano wrote:

> "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

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> 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.