Re: [PATCH] add status.relativePaths config variable

[Jeff King <peff@peff.net>]

On Fri, Dec 07, 2007 at 11:34:14PM -0800, Junio C Hamano wrote:

> I like the general idea (and suspect we might want to make it default to
> false to retain the original behaviour, but I'd refrain from suggesting
> it, to keep the user experience stable during the upcoming -rc period).
> 
> We'd need an update to git-status documentation to mention the variable.

Patch is below; please squash it into the original.

It seems kind of silly to manually write the "Configuration" section for
git-status, though. It would be nice if our config.txt could be
annotated to mention which commands use which config variables, and
git-*.txt could automagically include the right sections.

> > -	wt_status_prepare(&s);
> > -	s.prefix = prefix;
> > +	wt_status_prepare(&s, prefix);
> 
> I have been wondering ever since receiving this patch if this is a good
> interface change.  Was there a problem if instead:
> 
> 	- The implementation of wt_status_prepare(&s) stays as before;
> 
> 	- run_status(), after calling wt_status_prepare(&s), notices the
>           configuration variable, and sets s.prefix conditionally;

That would work fine. My reasoning was: the point of wt_status_prepare
is to initialize the wt_status object. I thought the "whether to use
relative paths based on config" logic should be something that _every_
preparer uses. OTOH, when I wrote it, I never expected that anyone _but_
run_status would call it (I must confess to not really investigating why
git-revert needed it; looks like it is to find a dirty index or working
tree, which is a little silly, since as a side effect we will do a find
on all untracked files).

I am fine with either; your call. Documentation patch is below.

---
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index b0cb6bc..645dc85 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -42,7 +42,8 @@ template comments, and all the output lines are prefixed with '#'.
 
 The paths mentioned in the output, unlike many other git commands, are
 made relative to the current directory, if you are working in a
-subdirectory (this is on purpose, to help cutting and pasting).
+subdirectory (this is on purpose, to help cutting and pasting). See
+the status.relativePaths config option below.
 
 
 CONFIGURATION
@@ -53,6 +54,10 @@ mean the same thing and the latter is kept for backward
 compatibility) and `color.status.<slot>` configuration variables
 to colorize its output.
 
+If the config variable `status.relativePaths` is set to false, then all
+paths shown are relative to the repository root, not to the current
+directory.
+
 See Also
 --------
 gitlink:gitignore[5]