Re: [PATCH] sparse-checkout.txt: new document with sparse-checkout directions

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 27, 2022, 15:43 UTC
Message-ID: <xmqqczbg9613.fsf@gitster.g>
In-Reply-To: <pull.1367.git.1664064588846.gitgitgadget@gmail.com>

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> +  * Does the name --[no-]restrict sound good to others?  Are there better options?

Everybody in this thread are interested in sparse checkout, which unfortunately blinds them from the fact that "restrict to", "limit to", "focus on", etc. need not to be limited to the sparse checkout feature. We must have something that hints that the option is about the sparse checkout feature.

As to the verbs, I do not mind "restrict to". Other good ones I do not mind choosing are "limit to" and "focus on". They would equally convey the same thing in this context. And the object for these verb phrases are the area of interest, those paths without the skip-worktree bit, the paths outside the sparse cone(s).

Or we could go the other way. We are excluding those paths with the skip-worktree bit, so "exclude" and "ignore" are natural candidates.

These two classes are good if the "restrict" behaviour will never be the default. When it is the default, the option often used will become "--no-restrict", which is awkward.

	Personally I am slightly in favor of "focus on" (i.e.
	"--focus" vs "--unfocus") as that meshes well with the
	concept of "the areas of the working tree paths that I am
	interested in right now", which may already hint that the
	option is about the sparse checkout feature (i.e. "I am
	focusing on these areas right now") and can stay short.  But
	this is just one person's opinion.

Show 5 quoted lines

> +      * `--sparse`, as used in add/rm/mv, is totally backwards for
> +	grep/log/etc.  Changing the meaning of `--sparse` for these
> +	commands would fix the backwardness, but possibly break existing
> +	scripts.  Using a new name pairing would allow us to treat
> +	`--sparse` in these commands as a deprecated alias.

I actually am in favor of this, even though the appearance of breaking backward compatibility may be big, but ...

> +      * There is a different `--sparse`/`--dense` pair for commands using
> +	revision machinery, so using that naming might cause confusion

... that is a good reason to avoid these two words.