Re: filtering out mode-change-only changes

From: Neal Kreitzinger <nkreitzinger@gmail.com>
Date: Feb 29, 2012, 19:11 UTC
Message-ID: <4F4E7847.9030402@gmail.com>
In-Reply-To: <7vipiqwb2g.fsf@alter.siamese.dyndns.org>

On 2/28/2012 9:52 PM, Junio C Hamano wrote:

Show 22 quoted lines

> Junio C Hamano<gitster@pobox.com>  writes:
>
>> "Neal Kreitzinger"<neal@rsss.com>  writes:
>>
>>> 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