Re: [PATCH] cvsserver: Make always-binary mode a config file option

From: Andy Parkins <andyparkins@gmail.com>
Date: Mar 1, 2007, 09:41 UTC
Message-ID: <200703010941.20161.andyparkins@gmail.com>
In-Reply-To: <46a038f90703010113o256f19a2qb1c16f4c85e5bd1c@mail.gmail.com>

On Thursday 2007 March 01 09:13, Martin Langhoff wrote:

> Well... the guys working on the MinGW port of git have railroaded us
> with the opposite position. If it's going to work in Windows, you
> better accept it has to handle newline conversion correctly or it's
> broken...

I do accept that, but as you said - it's broken whether you pick all binary or all text. I'm not advocating that my solution is final, but it is better to not convert text than to mangle binary.

Show 8 quoted lines

> The interesting case to fix this for is a mixed binary and text repo
> with windows users wanting newline conversion (if they really don't,
> they can tell TortoiseCVS as much). For that scenario, current
> behaviour is broken (binaries get mangled), and setting -kb on
> everything breaks newline conversion.
>
> And that scenario can only be addressed sending appropriate flags for
> each file, not with a blanket switch.

Erm, yes, I know that. But who is going to set that switch? This isn't real CVS where the repository records that information. At the moment git does not know whether any given file is binary or text.

> Except that it's not that hard to do something better -- I was hoping
> to prep a patch today, but things got frantic at the office.

I think it is hard; as git doesn't supply the needed information. I suppose it could be stored in the SQLlite table, but that is seriously borked. That table is a necessary evil, not a place to start storing any old flag.

> Just that I think it's easy enough to implement something that sets
> -k mode on file extension, which is actually _much_ better and makes
> the blanket setting pointless. And perhaps we can get binary
> autodetection working well but accepting overrides.

As I said, I don't like autodetection. It /will/ get it wrong. As for using file extension - well that's wrong too if it's coded into the source.

In a previous life, I used to develop a unix program on a windows computer; the UNIX directory was mounted as a samba share and built and run via an ssh connection. How is git-cvsserver meant to know about a crazy situation like that and "auto-detect" the right thing? It can't.

Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com