Re: checkout extra files

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

On Mon, Sep 3, 2012 at 8:42 PM, Angelo Borsotti
[off-list ref] wrote:

quoted

$ git checkout 94d8 -- *
$ ls
f1

Note that the work directory is empty when the checkout is done, and
that the checkout restores f1
in it, a file that is not denoted by the * pathspec.

I think in this case '*' remains unexpanded by the shell. Which means
it is still a pathspec to checkout (iow equivalent to "git checkout
94d8 -- '*'"). Checkout in turns matches the pathspec '*' against the
tree and decides to restore 'fl'.

It's confusing but I don't think there's much we can do about it.

The user can, by telling the shell to expand '*' that does not match
to nothing, though.

Is there anything that is confusing in our documentation?  I am not
looking for a change to the documentation that protects it from
getting misunderstood by deliberately twisted interpretations (such
a change would make the resulting text would harder to read), but I
do want to make sure it is not prone to confusion even to a casual
and careless reader.

For this particular scenario, I do not see anything offhand that is
unclear about the behaviour of Git in the documentation, even though
as you pointed out, if the user is unaware that the shell passes
globs unmodified when they do not match, it may lead to a confusion
like this.  I certainly do not want to do a full "introduction to
shell" in our documentation, but if adding a short sentence or two
helps to avoid confusion like this, I do not strongly object to it.

On Tue, Sep 4, 2012 at 2:36 AM, Junio C Hamano [off-list ref] wrote:

quoted

It's confusing but I don't think there's much we can do about it.

The user can, by telling the shell to expand '*' that does not match
to nothing, though.

It works 99% the time, I don't think any users would bother setting
that or studying the shell at that detail, until they are surprised.

Is there anything that is confusing in our documentation?  I am not
looking for a change to the documentation that protects it from
getting misunderstood by deliberately twisted interpretations (such
a change would make the resulting text would harder to read), but I
do want to make sure it is not prone to confusion even to a casual
and careless reader.

For this particular scenario, I do not see anything offhand that is
unclear about the behaviour of Git in the documentation, even though
as you pointed out, if the user is unaware that the shell passes
globs unmodified when they do not match, it may lead to a confusion
like this.  I certainly do not want to do a full "introduction to
shell" in our documentation, but if adding a short sentence or two
helps to avoid confusion like this, I do not strongly object to it.

Yeah, one or two sentences about two level expansion might help new
users. I'll check that. Maybe in the pathspec definition, then split
that part of out glossary-content.txt to be included in pathspec-using
commands as a separate pathspec section. Too much?
-- 
Duy