Jeff King writes:
> Hmph. Isn't that what I suggested in my first email? :P
Until I read the current text I did not realize the trailing
paragraph was to apply only to point C (no "--" disambiguates and
throws errors) but somehow thought it was covering both point B
(with "--" you are strict) an
On Mon, Sep 10, 2012 at 12:35:05PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I would argue the opposite; if it is about a specific point, then put it
> > with the point. Otherwise, you are asking the reader to remember back to
> > an earlier point (that they may not even have read;
Jeff King writes:
> I would argue the opposite; if it is about a specific point, then put it
> with the point. Otherwise, you are asking the reader to remember back to
> an earlier point (that they may not even have read; in reference
> documentation, the point of a list is often to let readers s
On Mon, Sep 10, 2012 at 10:09:43AM -0700, Junio C Hamano wrote:
> > Does it make sense to join that final paragraph into what is now the
> > third bullet, and then add your new text (the fourth bullet) after?
>
> I am not sure. After re-reading it, I do not think the fileglob
> discussion belong
Jeff King writes:
>> When writing a script that is expected to handle random user-input, it is
>> a good practice to make it explicit which arguments are which by placing
>> disambiguating `--` at appropriate places.
>
> Look at the paragraph below your addition. It is typographically outside
On Fri, Sep 07, 2012 at 01:49:15PM -0700, Junio C Hamano wrote:
> -- >8 --
> gitcli: contrast wildcard given to shell and to git
>
> People who are not used to working with shell may intellectually
> understand how the command line argument is massaged by the shell
> but still have a hard time vi
Junio C Hamano writes:
> Angelo Borsotti writes:
>
>> It makes quite clear that the command accepts wildcards
>> (not expanded by the shell), which was is not clear in the current
>> man page (although one could imagine that could also be a
>> wildcard).
>>
>> P.S. In the man page there is also
From: "Junio C Hamano"
Matthieu Moy writes:
Junio C Hamano writes:
"Philip Oakley" writes:
Having said that, it would therefore be better to point folk at
gitcli
in a few more places, not just the 'see also' line at the very end
of
the general 'git' page, and buried within rev-parse.
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> "Philip Oakley" writes:
>>
>>> Having said that, it would therefore be better to point folk at gitcli
>>> in a few more places, not just the 'see also' line at the very end of
>>> the general 'git' page, and buried within rev-parse.
>>
>> Didn'
Junio C Hamano writes:
> "Philip Oakley" writes:
>
>> Having said that, it would therefore be better to point folk at gitcli
>> in a few more places, not just the 'see also' line at the very end of
>> the general 'git' page, and buried within rev-parse.
>
> Didn't we update the very early part o
"Philip Oakley" writes:
> Having said that, it would therefore be better to point folk at gitcli
> in a few more places, not just the 'see also' line at the very end of
> the general 'git' page, and buried within rev-parse.
Didn't we update the very early part of git(1) for exactly for that
reas
From: "Junio C Hamano"
Sent: Friday, September 07, 2012 9:49 PM
Junio C Hamano writes:
But that is not what is happening at all. What goes on is far
simpler than that.
- the shell sees '*', matches it against working tree files, to
obtain "f1" and "f2";
- the shell tells "git" to "che
Angelo Borsotti writes:
> It makes quite clear that the command accepts wildcards
> (not expanded by the shell), which was is not clear in the current
> man page (although one could imagine that could also be a
> wildcard).
>
> P.S. In the man page there is also a
>
> "*git checkout* [-p|--
Junio C Hamano writes:
> But that is not what is happening at all. What goes on is far
> simpler than that.
>
> - the shell sees '*', matches it against working tree files, to
>obtain "f1" and "f2";
>
> - the shell tells "git" to "checkout e6f935e -- f1 f2";
>
> - "git" looks into the tre
"Philip Oakley" writes:
> A comment about the need to quote wild cards would certainly be of
> advantage to many Windows users who won't have used a shell in that
> way before.
>
> Plus I suspect that a large fraction of basic unix/linux users will
> have never really considered the difference be
From: "Junio C Hamano"
Sent: Tuesday, September 04, 2012 9:44 PM
Angelo Borsotti writes:
The issue here is that the paths must denote filenames that are
present in the index
or tree-ish, so, wildcards are misleading since they would instead be
interpreted
with respect to the working directory
Angelo Borsotti writes:
> The issue here is that the paths must denote filenames that are
> present in the index
> or tree-ish, so, wildcards are misleading since they would instead be
> interpreted
> with respect to the working directory.
When you are talking to a shell (and you almost never di
Hi,
figuring out what the behavior is by guessing how a command is implemented and
what are its interactions with the shell is a bit hard for the user:
s/he should instead
get it from the documentation.
I tried to figure it out from the examples I have done, and as you
see, I did not get it
quite
Angelo Borsotti writes:
> That of "git checkout -- *" is the problem when the directory is empty.
> Note that this happens with the shell that is shipped with git (in the
> windows distro). A note in the documentation could help the user
> to understand this.
Passing unmatched glob intact to the
Junio C Hamano writes:
> Now we have f1 and f2 in the working tree.
>
>> $ git checkout e6f9 -- *
>
> That is the same as "git checkout e6f935e -- f1 f2", as the shell
> expanded "*" into "f1" and "f2".
>
>> error: pathspec 'f2' did not match any file(s) known to git.
>>
>> Note the error.
>
> Ye
Nguyen Thai Ngoc Duy writes:
> On Tue, Sep 4, 2012 at 9:55 AM, Junio C Hamano wrote:
>> Perhaps like this?
>
> Looks good. I was going to complain that this patch applied to
> git-checkout.txt only but I just saw git-add.txt also mentions about
> quoting wildcards. So I'm good.
Ok, with a log m
Angelo Borsotti writes:
> $ mkdir gittest
> $ cd gittest
> $ git init
> Initialized empty Git repository in d:/gittest/.git/
At this point, the working tree presumably is empty.
> $ touch f1
> $ git add f1
> $ git commit commit -m "first commit"
> [master (root-commit) e6f935e] first commit
>
Hi Duy,
the semantics of "git checkout -- '*'" is quite clear because there is
no expansion done by the shell. The wildcard is passed to git checkout,
that interprets is properly.
That of "git checkout -- *" is the problem when the directory is empty.
Note that this happens with the shell that is
On Tue, Sep 4, 2012 at 9:55 AM, Junio C Hamano wrote:
> Perhaps like this?
Looks good. I was going to complain that this patch applied to
git-checkout.txt only but I just saw git-add.txt also mentions about
quoting wildcards. So I'm good.
> diff --git i/Documentation/git-checkout.txt w/Documenta
Angelo Borsotti writes:
>"It updates the named paths in the working tree from the index file or
>from a named ..."
It checks out the contents of the named paths out of either the
index or out of the tree-ish and stores that to a file in the
working tree. The working tree is not consult
Hi all,
consider this example:
$ mkdir gittest
$ cd gittest
$ git init
Initialized empty Git repository in d:/gittest/.git/
$ touch f1
$ git add f1
$ git commit commit -m "first commit"
[master (root-commit) e6f935e] first commit
0 files changed
create mode 100644 f1
$ touch f2
$ git checkout e
Nguyen Thai Ngoc Duy writes:
>> 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 t
Keep it in the list.
Angelo Borsotti writes:
> Hi Carlos,
>>
>> That grouping is not what it's saying. It doesn't update the files that
>> exist in the working tree matching some glob. It updates the files in
>> the working tree from either the index or a treeish. The pathspec
>> refers, as alw
On Tue, Sep 4, 2012 at 2:36 AM, Junio C Hamano wrote:
>> 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 stu
Nguyen Thai Ngoc Duy writes:
> On Mon, Sep 3, 2012 at 8:42 PM, Angelo Borsotti
> wrote:
>> $ 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.
>
Angelo Borsotti writes:
[please keep it in the list]
> Hi Carlos,
>
> the behavior is quite clear, but the man pages do not describe it properly.
> The man pages state:
>
> "It updates the named paths in the working tree from the index file or
> from a named ...".
>
> In my example, the
On Mon, Sep 3, 2012 at 8:42 PM, Angelo Borsotti
wrote:
> $ 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
Angelo Borsotti writes:
> Hello,
>
> the man page of git checkout states:
>
> git checkout [-p|--patch] [] [--] ...
>
> It updates the named paths in the working tree from the index file or
> from a named ...
>
> This means that for each file denoted by pathspec, git tries to
> restore it from t
33 matches
Mail list logo
