Junio C Hamano [off-list ref] writes:
"Neal Kreitzinger" [off-list ref] writes:
quoted
What is the best way to filter out the "mode change only" entries from a
"name-status diff result" listing of changed files?
...
I do not know about random scripts people write, but there is nothing
built-in.
Having said that, if we _were_ to do this built-in, an obvious logical
place to do so is to define a new DIFF_OPT_IGNORE_EXECUTABLE_BIT, teach
"--ignore-executable-bit" command line option to diff_opt_parse(), and
then teach diff_resolve_rename_copy() to consider this bit when the code
originally set DIFF_STATUS_MODIFIED. Instead, the updated code that is
working under --ignore-executable-bit option would drop such a filepair
from diff_queued_diff.
I do not know if such a change is worth doing, though. It depends on the
real reason why do you have so many "mode change only" changes that would
make rebasing or cherry-picking too troublesome.
On 2/28/2012 9:52 PM, Junio C Hamano wrote:
Junio C Hamano[off-list ref] writes:
quoted
"Neal Kreitzinger"[off-list ref] writes:
quoted
What is the best way to filter out the "mode change only" entries from a
"name-status diff result" listing of changed files?
...
I do not know about random scripts people write, but there is nothing
built-in.
Having said that, if we _were_ to do this built-in, an obvious logical
place to do so is to define a new DIFF_OPT_IGNORE_EXECUTABLE_BIT, teach
"--ignore-executable-bit" command line option to diff_opt_parse(), and
then teach diff_resolve_rename_copy() to consider this bit when the code
originally set DIFF_STATUS_MODIFIED. Instead, the updated code that is
working under --ignore-executable-bit option would drop such a filepair
from diff_queued_diff.
I do not know if such a change is worth doing, though. It depends on the
real reason why do you have so many "mode change only" changes that would
make rebasing or cherry-picking too troublesome.
I see three parts to this issue that are related but also independent:
Questions:
(Q1) Is the user handling filemodes correctly in git?
(Q2) Why does the user need to interrogate filemodes in git?
(Q3) How are file modes interrogated by the user in git?
Some Answers:
Q1: Is the user handling filemodes correctly in git?
A1-1: (My Context)
Perhaps I'm not, but I'm not prepared to ignore filemodes. I think I
need to be aware of what's changing. Blasting everything with the linux
chmod 777 shotgun, or the git core.filemode=false shotgun does not seem
like the right answer to me. I need to do more homework on linux
permissions and git executable bit tracking.
A1-2: (General Context)
Some users do legitimately choose to have core.filemode=true and are
correct in doing so.
Q2: Why does the user need to interrogate filemodes in git?
A2-1: (My Context)
After a rebase we need to review what changed with a 4-way diff to have
the full context of merge-base, topic, upstream, and merged. Because we
are mere-mortals, we want to use gui side-by-side diff (ie, diffuse)
instead of 4-way combined diff. git-difftool only takes two file parms
so I have to write my own script. git-mergetool's can display 4-way diff
but insist on mangling the $MERGED file with their own attempts at
redoing the merge, ie. creating their own merge conflicts even though
$MERGED has no conflict markers on input.
A2-2: (General Context)
"Vendor code drops" (see git-rm manpage) can have substantial
file-mode-only changes along with real content changes due to incorrect
tar procedures and/or the vendor's filesystem being a "mode breaking
filesystem". Also, there are these human stdin's going about
capriciously with a free-will doing chmod's.
Q3: How are file modes interrogated by the user in git?
A3-1: (Some Current Options)
--name-status lumps file-mode-only changes and content changes together
under status "M".
--raw can be parsed to discern filemode changes concurrent with
identical content sha1's.
--summary "mode change" entries might also be usable to apply a filter
to --name-status results.
A3-2: (Some Desired Options)
--name-status learns a new status for file-mode-only changes (ie, "P"
for "P"ermissions).
--raw learns "P+x" and "P-x" in the status column to tell you if the
executable bit was added or removed.
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.
v/r,
neal