All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shourya Shukla <shouryashukla.oo@gmail.com>
To: laurent@spkdev.net
Cc: congdanhqx@gmail.com, git@vger.kernel.org, gitster@pobox.com,
	phillip.wood@dunelm.org.uk, sandals@crustytoothpaste.net
Subject: Re: [PATCH v5] diff: add config option relative
Date: Mon, 18 May 2020 17:16:30 +0530	[thread overview]
Message-ID: <20200518114630.GA30622@konoha> (raw)
In-Reply-To: <20200518094021.GA2069@spk-laptop>

Hello Laurent,

I have not worked in this part of Git before, please pardon my
ignorance. I went through the conversations held in this thread
Here are my inferences:

> The `diff.relative` boolean option set to `true` show only changes on
> the current directory and show relative pathnames to the current
> directory.

> Teach --no-relative to override earlier --relative

I think the message can be written better, maybe something like:

    The `diff.relative` boolean option set to `true` shows only changes
    in the current directory/value specified by the `path` argument of
    the `relative` option and shows pathnames relative to the
    aforementioned directory.

    Teach `--no-relative` to override the earlier `--relative`

> --- a/Documentation/config/diff.txt
> +++ b/Documentation/config/diff.txt
> @@ -105,6 +105,10 @@ diff.mnemonicPrefix::
>  diff.noprefix::
>  	If set, 'git diff' does not show any source or destination prefix.
> 
> +diff.relative::
> +	If set to 'true', 'git diff' does not show changes outside of the directory
> +	and show pathnames relative to the current directory.

In the second last line, it would be better to write is as:

    ... does not show changes outside of the current directory/the path
    provided as the argument in `relative`?

Even my version of the above line seems very crude and innaccurate, but
I think that we should take into account the `path` passed down to us
by the `--relative[=<path>]` option.

Moving on, what I wondered was that maybe making it a `true/false`
option would be better? Something like:

    git diff --relative=false //override the diff.relative setting
    git diff --relative=true <path> //works like the usual `relative`

And by the usual, I mean :
    git diff --relative[=<path>]

What do you think? I think it would be better than adding a new option.

Also, if I am not mistaken:

> @@ -5195,8 +5202,7 @@ static int diff_opt_relative(const struct option *opt,
>  {
>  	struct diff_options *options = opt->value;
> 
> -	BUG_ON_OPT_NEG(unset);
> -	options->flags.relative_name = 1;
> +	options->flags.relative_name = !unset;

This is the overriding part right?

BTW you mention the `no-relative` setting which will override the
`relative` option. I am not able to see where exactly is the occurence
of the `no-relative` option in the code? What I mean is that I am not
able to observe where exactly does the C code identify a `no-relative`
option from the command line input? Did I miss something out here?

All nits aside, it looks like a very good concept to me. Nice work! :)

Regards,
Shourya Shukla

  reply	other threads:[~2020-05-18 11:46 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-15 15:57 [PATCH] diff: add config option relative Laurent Arnoud
2020-05-15 22:22 ` Philip Oakley
2020-05-16 17:30   ` Laurent Arnoud
2020-05-15 23:31 ` brian m. carlson
2020-05-16  0:04   ` Junio C Hamano
2020-05-16 17:35     ` Laurent Arnoud
2020-05-16 17:38     ` [PATCH v3] " Laurent Arnoud
2020-05-16 18:33       ` Phillip Wood
2020-05-16 19:40         ` [PATCH v4] " Laurent Arnoud
2020-05-17  2:14           ` Đoàn Trần Công Danh
2020-05-17  2:48             ` Danh Doan
2020-05-17 15:12             ` Junio C Hamano
2020-05-18  9:40               ` [PATCH v5] " Laurent Arnoud
2020-05-18 11:46                 ` Shourya Shukla [this message]
2020-05-18 13:04                   ` Đoàn Trần Công Danh
2020-05-18 17:25                   ` Laurent Arnoud
2020-05-18 13:56                 ` Đoàn Trần Công Danh
2020-05-18 16:57                   ` Junio C Hamano
2020-05-18 19:12                     ` Đoàn Trần Công Danh
2020-05-18 20:37                       ` Junio C Hamano
2020-05-19  0:30                         ` Đoàn Trần Công Danh
2020-05-19 18:00                           ` Junio C Hamano
2020-05-19 19:39                             ` [PATCH v7] " Laurent Arnoud
2020-05-19 23:01                               ` Đoàn Trần Công Danh
2020-05-22 10:46                                 ` [PATCH v8] " Laurent Arnoud
2020-05-23  2:14                                   ` Đoàn Trần Công Danh
2020-05-22 10:48                                 ` [PATCH v7] " Laurent Arnoud
2020-05-18 17:03                   ` [PATCH v5] " Junio C Hamano
2020-05-18 17:21                     ` [PATCH v6] " Laurent Arnoud
2020-05-18 17:31                       ` Junio C Hamano
2020-05-18 17:33                         ` Junio C Hamano
2020-05-18 17:34                       ` Eric Sunshine
2020-05-18 19:19                       ` Đoàn Trần Công Danh
2020-05-18 20:02                         ` Junio C Hamano
2020-05-18 17:32                   ` [PATCH v5] " Laurent Arnoud
2020-05-18 16:19                 ` Eric Sunshine
2020-05-18 17:26                   ` Laurent Arnoud
2020-05-18  9:43             ` [PATCH v4] " Laurent Arnoud
2020-05-17 15:07         ` [PATCH v3] " Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200518114630.GA30622@konoha \
    --to=shouryashukla.oo@gmail.com \
    --cc=congdanhqx@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=laurent@spkdev.net \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.