From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: "Martin Langhoff" <martin.langhoff@gmail.com>
Subject: Re: [PATCH] cvsserver: Make always-binary mode a config file option
Date: Thu, 1 Mar 2007 09:41:16 +0000 [thread overview]
Message-ID: <200703010941.20161.andyparkins@gmail.com> (raw)
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.
> 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
next prev parent reply other threads:[~2007-03-01 9:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-22 15:04 git-cvsserver and binary files Andy Parkins
2007-02-22 16:06 ` [PATCH] Added "-kb" to all the entries lines sent to the client Andy Parkins
2007-02-22 20:37 ` Junio C Hamano
2007-02-27 13:45 ` [PATCH] cvsserver: Make always-binary mode a config file option Andy Parkins
2007-02-28 11:36 ` Martin Langhoff
2007-02-28 13:01 ` Andy Parkins
2007-02-28 23:40 ` Martin Langhoff
2007-03-01 8:40 ` Andy Parkins
2007-03-01 9:13 ` Martin Langhoff
2007-03-01 9:41 ` Andy Parkins [this message]
2007-03-01 9:46 ` Junio C Hamano
2007-03-01 10:04 ` Junio C Hamano
2007-03-01 11:03 ` Junio C Hamano
2007-03-01 11:40 ` Andy Parkins
2007-03-01 11:44 ` Karl Hasselström
2007-02-27 13:46 ` Andy Parkins
2007-02-27 23:56 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200703010941.20161.andyparkins@gmail.com \
--to=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
--cc=martin.langhoff@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).