"Nguyen Thai Ngoc Duy" <pclouds@xxxxxxxxx> writes:
> On 9/20/08, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
>> > - "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 ;-)
--
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
