git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
APAndy Parkins <andyparkins@gmail.com>
Date
Feb 28, 2007, 13:01 UTC
Message-ID
<200702281301.58026.andyparkins@gmail.com>
In-Reply-To
<46a038f90702280336k6d368b8aj88ce8d3d822b1789@mail.gmail.com>
On Wednesday 2007 February 28 11:36, Martin Langhoff wrote:
> I am a bit confused here... why would we want to do this? We don't
> want to support keyword expansion, and that happens at the server end

Well, at the moment you don't, but that might happen in the future with certain settings in .gitattributes. It might be nice to have a switch to disable that available. However, that's not why I added this.

> anyway. CVS clients are pretty dumb and will just write out the file
> we give them. When we are going to diff, they send the file to the
> server, and the server runs the diff. Etc. No smarts at the client end
> that care about -k options.

I think your supposition that no client cares about the -k options is wrong. CVS clients don't just write the file untouched. CVS stores all text files with UNIX line endings, the client then uses the text/binary flag to decide if line-ending conversion should happen. Checking out to unix would of course not require any conversion so the file would be untouched. Not so for Windows clients. That was what prompted me to make this patch. I keep some binary images in the git repository, when they were checked out with TortoiseCVS they were having all the 0x0a (LF) bytes changed to CR LF, and thus mangling the images. 

> Or are you trying to control newline mangling on Windows/Mac clients?
> I'm not even sure where that mangling happens. If that's the case, a

It seems to be happening in the client. In fact it's a given that it happens in the client as only the client knows what the local line ending rules are.

> repo-wide toggle is useless, you really want the per-file-type rules
> you mention.
"Useless" is a strong word; especially as I'm finding it very useful :-).

Yes, a per-file option would be better - but git has no support for that at present, so I need a work around. Most windows editors will cope fine with UNIX line endings, so not converting them doesn't cause a problem. On the other hand, mangling every binary file /does/ matter. So, for me, the better default is to not mangle anything (i.e. tell CVS that everything is binary and should be preserved as is).

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Previous: Martin LanghoffNext: Martin Langhoff
Message 6 of 17 in “git-cvsserver and binary files”
  1. Andy ParkinsFeb 22, 2007
  2. Added "-kb" to all the entries lines sent to the clientAndy Parkins, Feb 22, 2007
  3. Junio C HamanoFeb 22, 2007
  4. cvsserver: Make always-binary mode a config file optionAndy Parkins, Feb 27, 2007
  5. Martin LanghoffFeb 28, 2007
  6. Andy ParkinsFeb 28, 2007
  7. Martin LanghoffFeb 28, 2007
  8. Andy ParkinsMar 1, 2007
  9. Martin LanghoffMar 1, 2007
  10. Andy ParkinsMar 1, 2007
  11. Junio C HamanoMar 1, 2007
  12. Junio C HamanoMar 1, 2007
  13. Junio C HamanoMar 1, 2007
  14. Andy ParkinsMar 1, 2007
  15. Karl HasselströmMar 1, 2007
  16. cvsserver: Make always-binary mode a config file optionAndy Parkins, Feb 27, 2007
  17. Junio C HamanoFeb 27, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.