By default, git-diff shows changes and pathnames relative to the
repository root.
Setting the diff.relative config option to "true" shows pathnames
relative to
the current directory and excludes changes outside this directory.
---
Documentation/diff-config.txt | 6 ++++++
diff.c | 8 ++++++++
t/t4045-diff-relative.sh | 21 +++++++++++++++++++++
3 files changed, 35 insertions(+)
@@ -182,3 +182,9 @@ diff.algorithm:: low-occurrence common elements". -- +++diff.relative::+ By default, linkgit:git-diff[1] shows changes and pathnames+ relative to the repository root. Setting this variable to+ `true` shows pathnames relative to the current directory and+ excludes changes outside this directory.
@@ -69,5 +86,9 @@ for type in diff numstat stat raw; docheck_$typefile2--relative=subdircheck_$typedir/file2--relative=subdone+fortypeinconfig;do+check_$typefile2subdir/+check_$typefile2subdir+donetest_done
That is quite manageable. I was concerned that --relative changes the UI
(relative paths) and behavior (excluding files outside the current
directory), which might not be clear if placed in just the UI component.
You make a great point that git_diff_basic_config drives other commands
though, like git-bisect, which --relative would not effect.
-----Original Message-----
From: Duy Nguyen <redacted>
Sent: 12/11/2014 08:37 AM
To: Kelson <redacted>
CC: Git Mailing List <redacted>
Subject: Re: [PATCH] added git-config support for diff.relative setting
On Thu, Dec 11, 2014 at 2:28 PM, Kelson [off-list ref] wrote:
quoted hunk
@@ -270,6 +270,14 @@ int git_diff_basic_config(const char *var, const char
By default, git-diff shows changes and pathnames relative to the
repository root. Setting the diff.relative config option to "true" shows
pathnames relative to the current directory and excludes changes outside
this directory.
Signed-off-by: Brandon Phillips <redacted>
---
Documentation/diff-config.txt | 6 ++++++
diff.c | 8 ++++++++
t/t4045-diff-relative.sh | 21 +++++++++++++++++++++
3 files changed, 35 insertions(+)
@@ -182,3 +182,9 @@ diff.algorithm:: low-occurrence common elements". -- +++diff.relative::+ By default, linkgit:git-diff[1] shows changes and pathnames+ relative to the repository root. Setting this variable to+ `true` shows pathnames relative to the current directory and+ excludes changes outside this directory.
@@ -69,5 +86,9 @@ for type in diff numstat stat raw; docheck_$typefile2--relative=subdircheck_$typedir/file2--relative=subdone+fortypeinconfig;do+check_$typefile2subdir/+check_$typefile2subdir+donetest_done
By default, git-diff shows changes and pathnames relative to the
repository root.
Setting diff.relative to "true" shows pathnames relative to the current
directory
and excludes changes outside this directory.
---
Documentation/diff-config.txt | 5 +++++
diff.c | 8 ++++++++
t/t4045-diff-relative.sh | 21 +++++++++++++++++++++
3 files changed, 34 insertions(+)
@@ -103,6 +103,11 @@ diff.orderfile:: one shell glob pattern per line. Can be overridden by the '-O' option to linkgit:git-diff[1].+diff.relative::+ Show pathnames relative to the current directory and exclude+ changes outside this directory; equivalent to the 'git diff'+ option '--relative'.+ diff.renameLimit:: The number of files to consider when performing the copy/rename detection; equivalent to the 'git diff' option '-l'.
@@ -69,5 +86,9 @@ for type in diff numstat stat raw; docheck_$typefile2--relative=subdircheck_$typedir/file2--relative=subdone+fortypeinconfig;do+check_$typefile2subdir/+check_$typefile2subdir+donetest_done
By default, git-diff shows changes and pathnames relative to the
repository root.
Setting diff.relative to "true" shows pathnames relative to the current
directory
and excludes changes outside this directory.
---
Documentation/diff-config.txt | 5 +++++
diff.c | 8 ++++++++
t/t4045-diff-relative.sh | 21 +++++++++++++++++++++
3 files changed, 34 insertions(+)
@@ -103,6 +103,11 @@ diff.orderfile:: one shell glob pattern per line. Can be overridden by the '-O' option to linkgit:git-diff[1].+diff.relative::+ Show pathnames relative to the current directory and exclude+ changes outside this directory; equivalent to the 'git diff'+ option '--relative'.+ diff.renameLimit:: The number of files to consider when performing the copy/rename detection; equivalent to the 'git diff' option '-l'.
@@ -69,5 +86,9 @@ for type in diff numstat stat raw; docheck_$typefile2--relative=subdircheck_$typedir/file2--relative=subdone+fortypeinconfig;do+check_$typefile2subdir/+check_$typefile2subdir+donetest_done
@@ -448,6 +448,10 @@ ifndef::git-format-patch[] not in a subdirectory (e.g. in a bare repository), you can name which subdirectory to make the output relative to by giving a <path> as an argument.++--no-relative::+ Turn off relative pathnames and include all changes in the+ repository. endif::git-format-patch[] -a::
@@ -448,6 +448,10 @@ ifndef::git-format-patch[] not in a subdirectory (e.g. in a bare repository), you can name which subdirectory to make the output relative to by giving a <path> as an argument.++--no-relative::+ Turn off relative pathnames and include all changes in the+ repository. endif::git-format-patch[] -a::
Subject: Re: [PATCH 1/2] support for --no-relative and diff.relative
"diff: teach --no-relative to override earlier --relative" or
something. Saying the affeced area upfront, terminated with a colon
':', will make it easier to spot in "git shortlog" output later.
Also this step is not about --no-relative and diff.relative but is
only about --no-relative option.
added --no-relative option for git-diff (code, documentation, and tests)
"Add --no-relative option..."; we write in imperative, as if we are
giving an order to the project secretary to "make the code do/be so".
--no-relative overrides --relative causing a return to standard behavior
OK (modulo missing full-stop).
Signed-off-by: Brandon Phillips <redacted>
Please also have
From: Brandon Phillips [off-list ref]
as the first line of the body of your e-mail message, if you are
letting your MUA only give your e-mail address without name.
Alternatively, please ask/configure your MUA to put your name as
well as your address on From: header of the e-mail (which is
preferrable).
When "--relative" is given, options->prefix is set to something as
we can see above.
The --relative option is described as optionally taking <path> in
the doc:
--relative[=<path>]::
When run from a subdirectory of the project, it can be
told to exclude changes outside the directory and show
pathnames relative to it with this option. When you are
not in a subdirectory (e.g. in a bare repository), you
can name which subdirectory to make the output relative
to by giving a <path> as an argument.
Doesn't "--no-relative" codepath have to undo the effect of that
assignment to options->prefix?
For example, after applying this patch, shouldn't
$ cd t
$ git show --relative=Documentation --no-relative --relative
work the same way as
$ cd t
$ git show --relative
i.e. limiting its output to the changes in the 't/' directory and
not to the changes in the 'Documentation/' directory?
Patch 2/2 also seems to share similar line-wrapping breakages that
make it unappliable, but more importantly, the configuration that is
supposed to correspond to --relative option only parses a boolean.
Is that the right design, or should it also be able to substitute a
command line `--relative=<path>` with an argument?
The last was a half-way rhetorical question and my answer is that
boolean-only is the best you could do, because we cannot do the
usual "bool or string" trick when "string" can be arbitrary. In
other words, "diff.relative=true" could mean "limit to the current
subdirectory" aka "--relative" or it could mean "limit to true/
subdirectory" aka "--relative=true", and there is no good way to
disambiguate between the two [*1*].
So I can agree with the design decision but only after spending 6
lines to think about it. For the end-users, this design decision
needs to be explained and spelled out in the documentation. Saying
"equivalent to `--relative`" is not sufficient, because the way
`--relative` option itself is described elsewhere. The option
appears as `--relative[=<path>]` (see above), so some people _will_
read "equivalent to `--relative`" to mean "Setting diff.relative=t
should be equivalent to --relative=t", which is not what actually
happens.
[Footnote]
*1* Actually, you could declare that "diff.relative=true/" means the
'true/' directory while "diff.relative=true" means the boolean
'true' aka 'diff --relative', but I think it is too confusing.
Let's not make it worse by going that route.
Also this step is not about --no-relative and diff.relative but is only about --no-relative option.
Should I submit as two independent patches then? I took the approach of
splitting them out into 1/2 vs 2/2 to distinguish, but it sounds like
that isn't optimal.
When "--relative" is given, options->prefix is set to something as we can see above.
The --relative option is described as optionally taking <path> in the doc:
...
Doesn't "--no-relative" codepath have to undo the effect of that assignment to options->prefix?
diff_setup_done NULLs options->prefix when DIFF_OPT_TST(options,
RELATIVE_NAME) is cleared (--no-relative clears this option).
On review, this may be a bad approach though. Non-locality makes it
harder to follow/understand and introduces a subtle bug.
current: "git-diff --relative=path --no-relative --relative" ==
"git-diff --relative=path"
expected: "git-diff --relative=path --no-relative --relative" ==
"git-diff --relative"
So I can agree with the design decision but only after spending 6
lines to think about it. For the end-users, this design decision
needs to be explained and spelled out in the documentation.
Agreed; update to come.
-----Original Message-----
From: Junio C Hamano <redacted>
Sent: 01/07/2015 01:09 PM
To: kelson@shysecurity.com
CC: Git Mailing List <redacted>, Philip Oakley
[off-list ref], Duy Nguyen [off-list ref], Jonathan
Nieder [off-list ref]
Subject: Re: [PATCH 1/2] support for --no-relative and diff.relative
Subject: Re: [PATCH 1/2] support for --no-relative and diff.relative
"diff: teach --no-relative to override earlier --relative" or
something. Saying the affeced area upfront, terminated with a colon
':', will make it easier to spot in "git shortlog" output later.
Also this step is not about --no-relative and diff.relative but is
only about --no-relative option.
added --no-relative option for git-diff (code, documentation, and tests)
"Add --no-relative option..."; we write in imperative, as if we are
giving an order to the project secretary to "make the code do/be so".
--no-relative overrides --relative causing a return to standard behavior
OK (modulo missing full-stop).
Signed-off-by: Brandon Phillips <redacted>
Please also have
From: Brandon Phillips [off-list ref]
as the first line of the body of your e-mail message, if you are
letting your MUA only give your e-mail address without name.
Alternatively, please ask/configure your MUA to put your name as
well as your address on From: header of the e-mail (which is
preferrable).
When "--relative" is given, options->prefix is set to something as
we can see above.
The --relative option is described as optionally taking <path> in
the doc:
--relative[=<path>]::
When run from a subdirectory of the project, it can be
told to exclude changes outside the directory and show
pathnames relative to it with this option. When you are
not in a subdirectory (e.g. in a bare repository), you
can name which subdirectory to make the output relative
to by giving a <path> as an argument.
Doesn't "--no-relative" codepath have to undo the effect of that
assignment to options->prefix?
For example, after applying this patch, shouldn't
$ cd t
$ git show --relative=Documentation --no-relative --relative
work the same way as
$ cd t
$ git show --relative
i.e. limiting its output to the changes in the 't/' directory and
not to the changes in the 'Documentation/' directory?
Patch 2/2 also seems to share similar line-wrapping breakages that
make it unappliable, but more importantly, the configuration that is
supposed to correspond to --relative option only parses a boolean.
Is that the right design, or should it also be able to substitute a
command line `--relative=<path>` with an argument?
The last was a half-way rhetorical question and my answer is that
boolean-only is the best you could do, because we cannot do the
usual "bool or string" trick when "string" can be arbitrary. In
other words, "diff.relative=true" could mean "limit to the current
subdirectory" aka "--relative" or it could mean "limit to true/
subdirectory" aka "--relative=true", and there is no good way to
disambiguate between the two [*1*].
So I can agree with the design decision but only after spending 6
lines to think about it. For the end-users, this design decision
needs to be explained and spelled out in the documentation. Saying
"equivalent to `--relative`" is not sufficient, because the way
`--relative` option itself is described elsewhere. The option
appears as `--relative[=<path>]` (see above), so some people _will_
read "equivalent to `--relative`" to mean "Setting diff.relative=t
should be equivalent to --relative=t", which is not what actually
happens.
[Footnote]
*1* Actually, you could declare that "diff.relative=true/" means the
'true/' directory while "diff.relative=true" means the boolean
'true' aka 'diff --relative', but I think it is too confusing.
Let's not make it worse by going that route.