Neal Kreitzinger <nkreitzinger@xxxxxxxxx> writes: > A3-2: (Some Desired Options) > --name-status learns a new status for file-mode-only changes (ie, "P" > for "P"ermissions). After reading everything above I omitted from your response in my quote, I still do not get the feeling that these willy-nilly mode changes that you are suffering from is a problem that is general enough to warrant such a change, even if such a change is done as an optional feature. Calling our executable bits "Permission" is a misnomer, by the way. It is more about "is this an executable file?" attribute, and is not "are you allowed to execute this?" permission. > --raw learns "P+x" and "P-x" in the status column to tell you if the > executable bit was added or removed. As --raw output by definition is designed to be read by scripts that can and do parse its output, I do not see how this can be a useful addition at all. The same information is available in the separate mode column already. > I wonder if filemode tracking was somewhat of an afterthought of the > content-is-king design of git and that is why it is semi-opaque. Our blobs represent contents. Whether your shell script has or does not have executable bits, the file has the same contents. The executable-ness of a particular file starts to matter only when you extract it to your working tree. The executable-ness matters equally as its contents, and as the path at which it is extracted. All three are recorded in an entry in a tree object and in an entry in the index, as a <mode, object name, path> tuple. At the end-user level, you seldom use the blob contents (identified by the object name in the three tuple explained above) alone without the surrounding context (the other two members of the three tuple) the blob appears in. Especially in "diff", you not only want to view the content change, but also need to know the change of the context in which the blobs appear in. And that is why we show "This content, or a related old version of it, appeared at this old path, but now it appears at this new path with the following change, and it lost the executable bit during the change." I do see nothing afterthought about the design at the storage or at the presentation level. -- 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