On 3/1/07, Andy Parkins <andyparkins@xxxxxxxxx> wrote:
> 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.
Ok - that's an interesting bit of info. I wasn't sure.
> 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 :-).
I guess what I mean is that the common case on windows is going to be for users who want their binary files un-corrupted, and their text files newline-converted. In fact, I think we should have it set to default to binary -- which does the best job of preserving data. And override that based on file extension (configurable) or check the "head" of the file cheaply for binary-ness before we update the file on the client side. I agree with the idea of doing something smart with -kb flags, but this is not a good move. For the common case among Windows TortoiseCVS users, the switch proposed introduces the ability to switch between one broken mode to another broken mode. (And in terms of temporary workarounds, TortoiseCVS has a switch in itself to disable newline conversion.) cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html