[PATCH] git-show.txt: mention that object path must be relative in EXAMPLES.

[PATCH] git-show.txt: mention that object path must be relative in EXAMPLES.

[Jari Aalto]

Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
 Documentation/git-show.txt |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 48b612e..2a014cc 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -57,7 +57,11 @@ git show v1.0.0^\{tree\}::
 git show next~10:Documentation/README::
 	Shows the contents of the file `Documentation/README` as
 	they were current in the 10th last commit of the branch
-	`next`.
+	`next`. *Note:* the 'object' path must always be relative to git
+	project root. This wouldn't have worked:
+
+	$ cd Documentation
+	$ git show next~10:README
 
 git show master:Makefile master:t/Makefile::
 	Concatenates the contents of said Makefiles in the head
-- 
1.5.6.5

Re: [PATCH] git-show.txt: mention that object path must be relative in EXAMPLES.

[Jakub Narebski]

Jari Aalto <jari.aalto@cante.net> writes:

> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
> ---
>  Documentation/git-show.txt |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
> index 48b612e..2a014cc 100644
> --- a/Documentation/git-show.txt
> +++ b/Documentation/git-show.txt
> @@ -57,7 +57,11 @@ git show v1.0.0^\{tree\}::
>  git show next~10:Documentation/README::
>  	Shows the contents of the file `Documentation/README` as
>  	they were current in the 10th last commit of the branch
> -	`next`.
> +	`next`. *Note:* the 'object' path must always be relative to git
> +	project root. This wouldn't have worked:
> +
> +	$ cd Documentation
> +	$ git show next~10:README

Actually that is not exactly true.  In the <tree-ish>:<path> the
'object' path must be always relative to <tree-ish), in this case
to "next~10", which means relative to project root at given commit
(important in case of subtree merge).

Although in practice <tree-ish> is always commit.

>  
>  git show master:Makefile master:t/Makefile::
>  	Concatenates the contents of said Makefiles in the head
> -- 
> 1.5.6.5
> 
> 

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [PATCH] git-show.txt: mention that object path must be relative in EXAMPLES.

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

On Saturday 07 February 2009 17:31:47 Jakub Narebski wrote:
> Jari Aalto <jari.aalto@cante.net> writes:
> > @@ -57,7 +57,11 @@ git show v1.0.0^\{tree\}::
> >  git show next~10:Documentation/README::
> >  	Shows the contents of the file `Documentation/README` as
> >  	they were current in the 10th last commit of the branch
> > -	`next`.
> > +	`next`. *Note:* the 'object' path must always be relative to git
> > +	project root. This wouldn't have worked:
> > +
> > +	$ cd Documentation
> > +	$ git show next~10:README
>
> Actually that is not exactly true.  In the <tree-ish>:<path> the
> 'object' path must be always relative to <tree-ish), in this case
> to "next~10", which means relative to project root at given commit
> (important in case of subtree merge).

Also important if one of your commits moves everything into a subdirectory in 
preparation for adding new top-level directories.  Sure, everyone on this list 
always knows exactly what their project tree should look like from the first 
commit, but there may be users of git that aren't that sophisticated.  ;)

So, I think better additional text would simply be:
*Note:* the path is interpreted relative to the tree-ish.

A example of what not to do is probably not useful in this case.
-- 
Boyd Stephen Smith Jr.                   ,= ,-_-. =.
bss@iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] git-show.txt: mention that object path must be relative in EXAMPLES.

[Jari Aalto]

"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:

> On Saturday 07 February 2009 17:31:47 Jakub Narebski wrote:
>
>> Jari Aalto <jari.aalto@cante.net> writes:
>> > +	`next`. *Note:* the 'object' path must always be relative to git
>> > +	project root. This wouldn't have worked:
>> > +
>> > +	$ cd Documentation
>> > +	$ git show next~10:README
>>
>> Actually that is not exactly true.  In the <tree-ish>:<path> the
>> 'object' path must be always relative to <tree-ish), in this case
>> to "next~10", which means relative to project root at given commit
>> (important in case of subtree merge).
>
> Also important if one of your commits moves everything into a subdirectory in 
> preparation for adding new top-level directories.  Sure, everyone on this list 
> always knows exactly what their project tree should look like from the first 
> commit, but there may be users of git that aren't that sophisticated.  ;)
>
> So, I think better additional text would simply be:
> *Note:* the path is interpreted relative to the tree-ish.

Changed, See below.

> A example of what not to do is probably not useful in this case.

It is important to give examples. This is a common mistake:

    $ cd todir
    $ ls file.txt
    file.txt

    $ git show 8b2de93:file.txt

    fatal: ambiguous argument '8b2de93:file.txt':
    unknown revision or path not in the working tree.

The path is in working tree from user's point of view but Git expects
it from project root. Not intuitive if you're deep/in/the/directory/hierarchy

Jari

>From 9de53447e456aaf5ab64f616df76f05888cc0d76 Mon Sep 17 00:00:00 2001
From: Jari Aalto <jari.aalto@cante.net>
Date: Sun, 8 Feb 2009 09:43:57 +0200
Subject: [PATCH] git-show.txt: mention that object path must be relative in EXAMPLES.

Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
 Documentation/git-show.txt |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 48b612e..27f771b 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -57,7 +57,13 @@ git show v1.0.0^\{tree\}::
 git show next~10:Documentation/README::
 	Shows the contents of the file `Documentation/README` as
 	they were current in the 10th last commit of the branch
-	`next`.
+	`next`. *Note:* the path is interpreted relative to the tree-ish.
+	A typical mistake is that after changing to a subdirectory from
+	project root, the current' directory's filename is used:
+
+	$ cd Documentation
+	$ git show next~10:README		 # Error, needs path
+	$ git show next~10:Documentation/README  # Ok, relative to tree-ish
 
 git show master:Makefile master:t/Makefile::
 	Concatenates the contents of said Makefiles in the head
-- 
1.5.6.5

Re: [PATCH] git-show.txt: mention that object path must be relative in EXAMPLES.

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

On Sunday 08 February 2009 01:52:11 Jari Aalto wrote:
> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> > On Saturday 07 February 2009 17:31:47 Jakub Narebski wrote:
> >> Jari Aalto <jari.aalto@cante.net> writes:
> >> > +	`next`. *Note:* the 'object' path must always be relative to git
> >> > +	project root.
> >> Actually that is not exactly true.  In the <tree-ish>:<path> the
> >> 'object' path must be always relative to <tree-ish), in this case
> >> to "next~10", which means relative to project root at given commit
> >> (important in case of subtree merge).
> > Also important if one of your commits moves everything into a
> > subdirectory in preparation for adding new top-level directories.
> >
> > So, I think better additional text would simply be:
> > *Note:* the path is interpreted relative to the tree-ish.
>
> Changed, See below.

Thanks.

> > A example of what not to do is probably not useful in this case.
>
> It is important to give examples. This is a common mistake:
>
>     $ cd todir
>     $ ls file.txt
>     file.txt
>
>     $ git show 8b2de93:file.txt
>
>     fatal: ambiguous argument '8b2de93:file.txt':
>     unknown revision or path not in the working tree.

I agree with both of your statements.  I'm just not sure about the wisdom of 
giving an example of what *not* to do.  There's a lot more incorrect 
invocations of git there there are correct invocations.  Perhaps an example 
that illustrated to the user how the "unintuitive" behavior was *useful* would 
be better.

> The path is in working tree from user's point of view

No.  At least, not from a right-thinking user's point of view.  The phrase 
"working tree" has a very specific meaning in git, it is not "the current 
directory".

> Not intuitive if you're
> deep/in/the/directory/hierarchy

I'm not sure "not intuitive" is a useful metric.  Different people simply 
expect different results.  HCI studies are hard; we shouldn't assume we can 
guess their results so easily.

Even with my objections above, I'm still slightly positive toward the patch as 
is.
-- 
Boyd Stephen Smith Jr.                   ,= ,-_-. =.
bss@iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]