Fix cvsexportcommit with CR/LF line endings

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

From: Dustin Spicuzza <[email protected]>

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.

---
 git-cvsexportcommit.perl | 1 +
 1 file changed, 1 insertion(+)

index d13f02da95..fc00d5946a 100755
@@ -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

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.

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

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

Hi Junio,

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

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.