In .gitattributes are the following equivalent:
*.chm binary
*.chm -diff
I have tried *.chm binary but I am afraid it may still try to merge these files. Is -diff more appropriate for what I intend to do ?
Also, will this setting be applicable after a file of the given type has already been committed ?
Thanks
Thanks for your question, you asked:
I have tried
*.chmbinary but I am afraid it may still try to merge these files. Is-diffmore appropriate for what I intend to do ?
The built-in macro attribute binary is equivalent to:
[attr]binary -diff -merge -text
(ref: Defining Macro Attributes - Gitattributes)
So from your question being afraid that -diff over binary may be more appropriate: It is not that much of a difference. Both should normally suffice, the gitattributes documentation names -diff as one of the easiest ways to mark a file as binary. So why not go with it for .chm files?
See the following example which shows the effect of some of the attributes in your question:
.gitattributes file
[1] | [2] | [3]
------------------------|-----------------------|------------------------
*.chm binary | *.chm -diff | *.chm binary
*.chm -diff | |
$ git check-attr -a help.chm
------------------------|-----------------------|------------------------
help.chm: binary: set | help.chm: diff: unset | help.chm: binary: set
help.chm: diff: unset | | help.chm: diff: unset
help.chm: merge: unset | | help.chm: merge: unset
help.chm: text: unset | | help.chm: text: unset
REMARK:
[1]above is identical in output to the single-line*.chm -diff binaryor*.chm binary -diff. A strong hint that all these are logically equivalent to just*.chm binaryand different to*.chm -diff.
For the question if -diff is more appropriate for your intend, it depends on the other gitattributes in your configuration and which you deem appropriate or not. As you have not shared them in your question, I could consider them undefined for the answer (no offence here, attributes can be either set, unset or undefined). But then the answer would not be complete. So anything is possible and using the binary marco-attribute may unset or define a previously already set or undefined merge and/or text attribute being already effective in a repository configuration.
Therefore binary looks preferable over -diff to me only for pressing an answer (not likely good) as you are concerned about merging binary files and it is the binary macro attribute that unsets the merge attribute with the following consequences:
Unset
Take the version from the current branch as the tentative merge result, and declare that the merge has conflicts. This is suitable for binary files that do not have a well-defined merge semantics.
(ref: merge - Performing a three-way merge - Gitattributes)
This is the same as using the binary built-in merge driver. So like the binary macro-attribute suggests, you mark the merge explicitly as "binary".
In difference to -diff - which also implicitly marks the file as binary - the binary macro-attribute does change the merge attribute and therefore unsetting the diff attribute allows to have a different than the unset merge attribute merge driver in action (this is where the existing answer is correct, using binary is not the same as -diff - it was incomplete listing the attributes of the macro thought and missed the unset of the merge attribute - it may not have been documented for the version in use thought, maybe git version < 1.7.12.4).
As you perhaps can imagine these are pretty fine details. In short -diff should suffice, binary may not hurt, but unsets more attributes than normally necessary and therefore is more explicit on the merge (not mentioning the text attribute), but may have unwanted side-effects and/or make some future maintenance harder (this is pretty theoretical, however it might do that little more which made you afraid in the first place).
My personal answer is, don't be afraid and follow your own preference for -diff until you run into a practical problem. Most likely you have solved this already long-time ago.
Also thanks for the additional question you asked:
Also, will this setting be applicable after a file of the given type has already been committed ?
Yes.
When in doubt try it out with $GIT_DIR/info/attributes (which has the highest precedence) as it is local to your clone and is never committed, then verify with git check-attr how it affects the attributes of already committed files.
Git does not store the attributes in the repository per each committed file, only in the .gitattributes file/s if it/they is/are committed.
They are not the same. binary is a built-in macro attribute and means -diff -text. See the MACRO ATTRIBUTES section of the gitattributes documentation for details.
