Re: [PATCH v2 00/14] Sparse checkout

"Nguyen Thai Ngoc Duy" [off-list ref] writes:

On 9/20/08, Jakub Narebski [off-list ref] wrote:

quoted

 >  - "git clone --path" => "git clone --narrow-path"
 >  - "git checkout --path" => "git checkout --reset-path"

I am not sure about that change, especially the fact that git-clone
 and git-checkout use differently named options, because those options
 affect clone only as they affect the checkout part of the clone.  One
 would think that git-clone = git-init + git-remote add + git-fetch +
 git-checkout, and that git-clone would simply pass sparse checkout
 flags to git-checkout.

Johannes sixt said --path was too generic so I changed the name. Hmm..
I did not think the same option name for git-checkout and git-clone
was important, rather worry about people may misunderstand that it is
"narrow clone" (do not fetch objects outside given paths for all
history). Maybe "git clone --narrow-checkout" would be better.

Be it narrow or sparse, I would agree this round is better than too
generic sounding --path.  Whatever that "limited set of paths that are to
appear in the working tree" is called, it is a good idea to name options
to clarify what effect each option causes on that concept X.  So perhaps:

	--reset-X	resets the checkout set
        --widen-X	widens the checkout set
        --narrow-X	narrows the checkout set

is a good set of options to give "checkout".

You could argue that using "--reset-X" would be more consistent for clone,
but I think the "--reset-" part is redundant, because clone cannot
possibly say "add these" or "subtract those".  I.e. it can only establish
the initial set (which is "--reset-X").  Which leads me to suggest that it
would not be such a good idea to use the same option name for clone and
checkout

With s/X/sparse/, above would give a set of options that does not sound
too bad, I think.  It certainly is better than s/X/narrow/ which would
have a strong "Huh?" factor in "--narrow-narrow" one ;-)