Re: [PATCH] add status.relativePaths config variable

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 8, 2007, 07:34 UTC
Message-ID: <7vejdxy70p.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20071207212607.GA11504@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 15 quoted lines

> The output of git-status was recently changed to output
> relative paths. Setting this variable to false restores the
> old behavior for any old-timers that prefer it.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> On Fri, Dec 07, 2007 at 03:49:37PM -0500, Jeff King wrote:
>
>> Personally, I don't like either the "../" or the "./", but I actually
>> think the relative paths are less readable than the full paths in
>> general.
>
> So here is a config option to turn it off; I don't think there should be
> any consistency problems, since git-status output is meant to be
> human-readable (and after all, we just changed it :) ).

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.

Show 11 quoted lines

> diff --git a/builtin-commit.c b/builtin-commit.c
> index 18c6323..04b3bf1 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -284,8 +284,7 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix)
>  {
>  	struct wt_status s;
>  
> -	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;