Re: --diff-filter=T does not list x changes

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: --diff-filter=T does not list x changes

From: Anders Melchiorsen <hidden>
Date: 2016-06-15 22:45:30

Junio C Hamano [off-list ref] writes:
Anders Melchiorsen [off-list ref] writes:
quoted
I hope you agree that this reading is not obvious from the
documentation,...
Yup, didn't I already say that the documentation is buggy?
Possibly, though not in this thread.

quoted
How about adding a diff-filter=X for the executable bit?
I do not think it is a good idea for two reasons. Backward
compatibility and sane design.

For one thing, "diff --name-status" never shows X, so you would
introduce an unnecessary inconsistency. If you change
"--name-status" to avoid that, you would be breaking people's
existing scripts that expect to see "M" for such a change.
(I noticed that X is already used in diff-filter, but will keep it for
this discussion)

I was thinking that X could be a subset of M. So only if you
specifically ask for diff-filter=X (and not M) would you get this new
functionality. That should keep it compatible. It would then pick
files that have had their x flipped, regardless of their change in
content. With diff-filter=M, it would work as it does today.

If name-status output must be consistent, it could even output M for
these changes. That would still be unambiguous (but probably confusing).

...

As you say that this is an unnecessary inconsistency, I wonder whether
you have a different way to pick out the commits that toggle the x
bit? That is a problem that I am facing, with no solution shown so far ...


Anders.

Re: --diff-filter=T does not list x changes

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:30

Anders Melchiorsen [off-list ref] writes:
... way to pick out the commits that toggle the x
bit? That is a problem that I am facing, with no solution shown so far ...
Are you interested in executable-bit only change, or any change that
contains changes to the executable-bit?  If I were looking for the latter,
probably finding "^:100664 100775 " (or the other way around) in log --raw
(or whatchanged) output would be what I would do --- the mode changes are
rare enough in a sane project, so I wouldn't mind having to do such
scripting as needed.

There are other "commit pickers" such as -S<strting> and --diff-filter
that do not absolutely have to exist (iow, they could also be scripted),
but what they pick earned easy shortcuts because the need is very common.
Once you can demonstrate that the need to pick executable-bit changes is
also very common, _and_ if you can come up with a clean solution, we might
add a commit picker that looks for changes in executable-ness in the
future.  I dunno.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help