Re: [PATCH] status: hint the user about -uno if read_directory takes too long

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Torsten Bögershausen wrote:
> [PATCH] git status: Document that git status -uno is faster

Yes.  I like this patch.

> In some repostories users expere that "git status" command takes long time.
> The command spends some time searching the file system for untracked files.
> Document that searching for untracked file may take some time, and docuemnt
> the option -uno better.

Please correct the typos in the commit message.

> Signed-off-by: Torsten Bögershausen <tboegi@xxxxxx>
> ---
>  Documentation/git-status.txt | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
> index 0412c40..fd36bbd 100644
> --- a/Documentation/git-status.txt
> +++ b/Documentation/git-status.txt
> @@ -58,6 +58,13 @@ The possible options are:
>  The default can be changed using the status.showUntrackedFiles
>  configuration variable documented in linkgit:git-config[1].
>
> ++
> +Note: Searching the file system for untracked files may take some time.
> +git status -uno is faster than git status -uall.
> +There is a trade-off around the use of -uno between safety and performance.
> +The default is not to use -uno so that you will not forget to add a file
> you newly created (i.e safety).
> +You would pay for the safety with the cost to find such untracked files
> (i.e. performance).

Good writeup.  What -uno does is already documented, so you've
explained the trade-off.
Why didn't you just wrap the paragraph to 80 columns though?
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]