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
Jeff King p...@peff.net 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
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 belongs to
Jeff King p...@peff.net 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
On Mon, Sep 10, 2012 at 12:35:05PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
Junio C Hamano gits...@pobox.com writes:
Philip Oakley philipoak...@iee.org 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Philip Oakley philipoak...@iee.org 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
From: Junio C Hamano gits...@pobox.com
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Philip Oakley philipoak...@iee.org writes:
Having said that, it would therefore be better to point folk at
gitcli
in a few more places, not just the 'see also'
Junio C Hamano gits...@pobox.com writes:
Angelo Borsotti angelo.borso...@gmail.com 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 path could also be a
wildcard).
Angelo Borsotti angelo.borso...@gmail.com 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 path could also be a
wildcard).
P.S. In the man page there is also a
From: Junio C Hamano gits...@pobox.com
Sent: Friday, September 07, 2012 9:49 PM
Junio C Hamano gits...@pobox.com 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;
-
Philip Oakley philipoak...@iee.org 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
Junio C Hamano gits...@pobox.com 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 tree
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
On Tue, Sep 4, 2012 at 9:55 AM, Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com 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.
Yes?
Angelo Borsotti angelo.borso...@gmail.com 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
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 angelo.borso...@gmail.com 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
From: Junio C Hamano gits...@pobox.com
Sent: Tuesday, September 04, 2012 9:44 PM
Angelo Borsotti angelo.borso...@gmail.com 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
Angelo Borsotti angelo.borso...@gmail.com writes:
Hello,
the man page of git checkout states:
git checkout [-p|--patch] [tree-ish] [--] pathspec...
It updates the named paths in the working tree from the index file or
from a named tree-ish ...
This means that for each file denoted by
On Mon, Sep 3, 2012 at 8:42 PM, Angelo Borsotti
angelo.borso...@gmail.com 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 '*'
Angelo Borsotti angelo.borso...@gmail.com 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 tree-ish
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
On Mon, Sep 3, 2012 at 8:42 PM, Angelo Borsotti
angelo.borso...@gmail.com 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
On Tue, Sep 4, 2012 at 2:36 AM, Junio C Hamano gits...@pobox.com 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
Keep it in the list.
Angelo Borsotti angelo.borso...@gmail.com 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
Nguyen Thai Ngoc Duy pclo...@gmail.com 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
28 matches
Mail list logo
