[mingw port] git plumbing piping with CR/NL

[mingw port] git plumbing piping with CR/NL

[Nguyen Thai Ngoc Duy]

Hi,

I haven't had time looking at the code yet. I report here so that I
can free my memory for other things. I made a command like this:

$ git ls-tree -r HEAD|grep blah.cc|git update-index --index-info

and the output of git-status was:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	new file:   path/to/blah.cc\r
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#
#	deleted:    path/to/blah.cc\r
...
$ git version
git version 1.5.2.651.g80e39-dirty (if the commit isn't in the master
branch, it is based on master branch)

Apparently git should ignore \r at the end of the path. Will look at it later.
-- 
Duy

Re: [mingw port] git plumbing piping with CR/NL

[Alex Riesen]

Nguyen Thai Ngoc Duy, Fri, Jun 01, 2007 20:23:24 +0200:
> Hi,
> 
> I haven't had time looking at the code yet. I report here so that I
> can free my memory for other things. I made a command like this:
> 
> $ git ls-tree -r HEAD|grep blah.cc|git update-index --index-info
> 
> and the output of git-status was:
> 
> $ git status
> # On branch master
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> #	new file:   path/to/blah.cc\r
> #
> # Changed but not updated:
> #   (use "git add/rm <file>..." to update what will be committed)
> #
> #	deleted:    path/to/blah.cc\r
> ...
> $ git version
> git version 1.5.2.651.g80e39-dirty (if the commit isn't in the master
> branch, it is based on master branch)
> 
> Apparently git should ignore \r at the end of the path. ...

Why should it? \r is a valid character in filenames almost everywhere
(except for the some proprietary OSes, as usual).

Why does your grep _alters_ the input, instead of filtering it, btw?

Re: [mingw port] git plumbing piping with CR/NL

[Nguyen Thai Ngoc Duy]

On 6/1/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> Nguyen Thai Ngoc Duy, Fri, Jun 01, 2007 20:23:24 +0200:
> > Hi,
> >
> > I haven't had time looking at the code yet. I report here so that I
> > can free my memory for other things. I made a command like this:
> >
> > $ git ls-tree -r HEAD|grep blah.cc|git update-index --index-info
> >
> > and the output of git-status was:
> >
> > $ git status
> > # On branch master
> > # Changes to be committed:
> > #   (use "git reset HEAD <file>..." to unstage)
> > #
> > #     new file:   path/to/blah.cc\r
> > #
> > # Changed but not updated:
> > #   (use "git add/rm <file>..." to update what will be committed)
> > #
> > #     deleted:    path/to/blah.cc\r
> > ...
> > $ git version
> > git version 1.5.2.651.g80e39-dirty (if the commit isn't in the master
> > branch, it is based on master branch)
> >
> > Apparently git should ignore \r at the end of the path. ...
>
> Why should it? \r is a valid character in filenames almost everywhere
> (except for the some proprietary OSes, as usual).

Right. Although I doubt usage of \r and other special characters in filenames.

> Why does your grep _alters_ the input, instead of filtering it, btw?

I have no idea. It's grep from MKS Toolkit FYI.
-- 
Duy

Re: [mingw port] git plumbing piping with CR/NL

[Johannes Schindelin]

Hi,

On Fri, 1 Jun 2007, Nguyen Thai Ngoc Duy wrote:

> On 6/1/07, Alex Riesen <raa.lkml@gmail.com> wrote:
>
> > Why does your grep _alters_ the input, instead of filtering it, btw?
> 
> I have no idea. It's grep from MKS Toolkit FYI.

Your subject says "[mingw port]". You should have mentioned that you use a 
mixed setup, as the mingw port still depends on msys for the scripts.

Ciao,
Dscho

Re: [mingw port] git plumbing piping with CR/NL

[Alex Riesen]

Nguyen Thai Ngoc Duy, Sat, Jun 02, 2007 01:56:54 +0200:
> >Why does your grep _alters_ the input, instead of filtering it, btw?
> 
> I have no idea. It's grep from MKS Toolkit FYI.
>

Looks like it is buggy

Re: [mingw port] git plumbing piping with CR/NL

[Sam Vilain]

Alex Riesen wrote:
> > Apparently git should ignore \r at the end of the path. ...
> Why should it? \r is a valid character in filenames almost everywhere
> (except for the some proprietary OSes, as usual).
>   

So is \n!

Sam.