Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook

[Glen Ditchfield]

Glen Ditchfield wrote:
> You base the text/binary decision on the name of the file.  How hard
> would it be to base it on the contents of the file instead, the way the
> Unix 'file' command does?

On Friday 27 May 2005 14:44, rghetta replied:
> The hook uses only the filespec, true, but if it returns nil, monotone will
> check the file content for ASCII NULs and some other control chars.
I worry that, when monotone checks for control characters, it is not always 
good enough, and too late for a hook to fix things.  I would like to have a 
hook that sees that the first six bytes of the file are 
\320\317\021\340\241\261 and concludes "this is an MS Word file", instead of 
a hook that checks the file suffix for eight different case-sensitive 
variations of ".doc" and still guesses wrong sometimes.

This is related to Joel Crisp's point in an earlier posting.  What is the root 
problem?  Does monotone just have to spot the binary files, or does it have 
to get a more exact idea of each file's type so that it can invoke a 
type-specific merge function?  ("This is an MS Word file, so merge the 
revisions with Word".)

On Friday 27 May 2005 14:44, rghetta wrote:
> Unless adding .mt-attrs support is more or less trivial, my proposal is
> to merge the current patch to resolve the merging bug.
This may be one of those "good enough" solutions -- the kind where nobody ever  
gets around to coding up the "right thing" (in a way that would be 
backwards-compatible with the established "good enough" thing), and future 
generations just live with a small, nagging annoyance ...