Jeff King <peff@xxxxxxxx> writes:
> 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@xxxxxxxx>
> ---
> 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.
> 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;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
