From: Junio C Hamano <hidden> Date: 2016-08-11 19:38:11
Andy Parkins [off-list ref] writes:
On Wednesday 2006 December 13 22:56, Shawn Pearce wrote:
quoted
git cat-file -p $REV:$file
not sure how much easier it gets than that. Load in the bash
completion from contrib/completion and you can even tab complete
the $file part.
Yes. I was a little unfair on that one; I forgot about the REV:file syntax.
However, it's still not simple for a new user; I think I'd say "draw" if
the "-p" weren't a requirement.
I would say pretending as if cat-file is a Porcelain is the
unfair part.
$ git-ls-tree v1.0.0
100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8 Makefile
I'm a newbie: what's that number at the front? What's a blob? What's that
great big number - I've only seen commit hashes that look like that, and that
isn't one. Definitely not friendly.
Again, mistaking ls-tree as if it was a Porcelain is the true
cause of the newbie confusion.
It could probably be fixed by making git-ls-files capable of understanding
tree-ish.
I think that's a wrong way to go about. The primary purpose of
ls-files is to read the index and show information around it;
ls-tree is about reading one tree and show information around
it. They are both plumbing and meant to be used by scripts when
they want to inspect the index or a tree respectively.
If a Porcelain level "ls" is needed (and I am doubtful about
usefulness of "svn list -r538" like command), that is the
command you would want to teach about using ls-files and ls-tree
depending on what the end users want in their workflow.
From: Junio C Hamano <hidden> Date: 2016-08-11 19:26:27
Johannes Schindelin [off-list ref] writes:
Hi,
On Fri, 15 Dec 2006, Johannes Schindelin wrote:
quoted
On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:
quoted
About adding index support to git-show, yes it's really messy. index
doesn't have tree objects.
Insofar, it is not messy: git-show only shows _objects_. For example, "git
show :README" works as expected if you have a file called "README" in the
index...
Note: this is not completely true. The index contains cache_trees...
Let's not go there.
I was reviewing the list of plumbing in Documentation/git.txt
last night, and I think ls-files is the only command that user
may still want to use from the command line every day.
I originally thought that it would only be after a conflicted
merge, always with -u option, but some people seem to find that
"ls-files --others" and friends are useful (I never use that
myself) and if so what it does really in the realm of Porcelain.
I haven't formed a firm opinion on this yet, but possibilities
are:
* we reclassify ls-files as a Porcelain-ish (but do not change
its UI nor defaults at all); we might want to give a shorter
alias to the command, though, if we go this route.
* we give '--list' option to 'git show' and in such a case,
lack of objects does not default to HEAD -- when no object is
given it internally diverts to cmd_ls_files() instead;
* we add 'git ls' command to give Porcelain-ish access to
ls-tree and ls-files.
From: Johannes Schindelin <hidden> Date: 2016-08-11 19:33:47
Hi,
On Thu, 14 Dec 2006, Nguyen Thai Ngoc Duy wrote:
On 12/14/06, Junio C Hamano [off-list ref] wrote:
quoted
If a Porcelain level "ls" is needed (and I am doubtful about
usefulness of "svn list -r538" like command), that is the
command you would want to teach about using ls-files and ls-tree
depending on what the end users want in their workflow.
+1. Any chance git-ls can go to 1.5.0?
Two questions arise naturally:
- what do you need it for?
- have you seen the patch for git-show today, which would include this
functionality?
Ciao,
Dscho
Hi,
On 12/14/06, Johannes Schindelin [off-list ref] wrote:
quoted
quoted
- have you seen the patch for git-show today, which would include this
functionality?
I didn't. From the patch, it seems git-show can show the index via
::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is
not intuitive though. Perhaps you should mention that it can show
index (and how) in the git-show document
Well, you can reference blobs that way, but not trees.
Oh, yeah. Isn't this a good oppotunity to add --index option to git-show?
git-show --index will show the index. git-show --index file will show
the file content. This makes git-show a little unconsistent though as
it may or may not require argument <object>.
Another option is treat '::' alone specially -- call git-ls-files.
--
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:00:17
Hi,
On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:
About adding index support to git-show, yes it's really messy. index
doesn't have tree objects.
Insofar, it is not messy: git-show only shows _objects_. For example, "git
show :README" works as expected if you have a file called "README" in the
index...
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:04:04
Hi,
On Thu, 14 Dec 2006, Nguyen Thai Ngoc Duy wrote:
On 12/14/06, Johannes Schindelin [off-list ref] wrote:
quoted
Two questions arise naturally:
- what do you need it for?
for being user-friendly and consistent.
Okay, I only thought you had a use case, which could have been possibly
better served by other commands.
quoted
- have you seen the patch for git-show today, which would include this
functionality?
I didn't. From the patch, it seems git-show can show the index via
::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is
not intuitive though. Perhaps you should mention that it can show
index (and how) in the git-show document
Well, you can reference blobs that way, but not trees.
Ciao,
Dscho
If a Porcelain level "ls" is needed (and I am doubtful about
usefulness of "svn list -r538" like command), that is the
command you would want to teach about using ls-files and ls-tree
depending on what the end users want in their workflow.
Hi,
On 12/14/06, Johannes Schindelin [off-list ref] wrote:
Two questions arise naturally:
- what do you need it for?
for being user-friendly and consistent. Git porcelain commands seem to
be grouped by function. So it would be natural to have git-ls as a
front-end for both ls-files and ls-tree. I don't really care about
ls-tree but I do about ls-files to examine index.
- have you seen the patch for git-show today, which would include this
functionality?
I didn't. From the patch, it seems git-show can show the index via
::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is
not intuitive though. Perhaps you should mention that it can show
index (and how) in the git-show document
--
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:12:49
Hi,
On Fri, 15 Dec 2006, Johannes Schindelin wrote:
On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:
quoted
About adding index support to git-show, yes it's really messy. index
doesn't have tree objects.
Insofar, it is not messy: git-show only shows _objects_. For example, "git
show :README" works as expected if you have a file called "README" in the
index...
Note: this is not completely true. The index contains cache_trees. But
they do not need to be up-to-date, which would mean that "git show :./"
would have to remake the cache_tree, and _then_ show it.
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:37:50
Hi,
On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:
On 12/14/06, Johannes Schindelin [off-list ref] wrote:
quoted
quoted
quoted
- have you seen the patch for git-show today, which would include this
functionality?
I didn't. From the patch, it seems git-show can show the index via
::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is
not intuitive though. Perhaps you should mention that it can show
index (and how) in the git-show document
Well, you can reference blobs that way, but not trees.
Oh, yeah. Isn't this a good oppotunity to add --index option to git-show?
git-show --index will show the index. git-show --index file will show
the file content. This makes git-show a little unconsistent though as
it may or may not require argument <object>.
Another option is treat '::' alone specially -- call git-ls-files.
Hmm. I don't know... It would make the code rather messy. And are you
really interested in the content stored in the index? In all cases I can
think of, you are better off with a diff vs. working directory or ref.
Ciao,
Dscho
From: Andy Parkins <hidden> Date: 2016-08-11 20:42:01
On Thursday 2006 December 14 09:44, Junio C Hamano wrote:
I would say pretending as if cat-file is a Porcelain is the
unfair part.
I had to; there is no other equivalent of "svn cat" in git.
Again, mistaking ls-tree as if it was a Porcelain is the true
cause of the newbie confusion.
Again, there is no other equivalent of "svn list" in git.
If a Porcelain level "ls" is needed (and I am doubtful about
usefulness of "svn list -r538" like command), that is the
Me too. I was in no way advocating that git should try to be SVN (shudder).
As I was comparing though, I had to pick git commands that did at least what
SVN could do.
command you would want to teach about using ls-files and ls-tree
depending on what the end users want in their workflow.
Personally, I think qgit fills an awfully big hole in svn that makes them all
irrelevant. qgit is a much better repository browsing tool than "svn list"
is.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
Hi,
On 12/15/06, Johannes Schindelin [off-list ref] wrote:
Hi,
On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:
quoted
On 12/14/06, Johannes Schindelin [off-list ref] wrote:
quoted
quoted
quoted
- have you seen the patch for git-show today, which would include this
functionality?
I didn't. From the patch, it seems git-show can show the index via
::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is
not intuitive though. Perhaps you should mention that it can show
index (and how) in the git-show document
Well, you can reference blobs that way, but not trees.
Oh, yeah. Isn't this a good oppotunity to add --index option to git-show?
git-show --index will show the index. git-show --index file will show
the file content. This makes git-show a little unconsistent though as
it may or may not require argument <object>.
Another option is treat '::' alone specially -- call git-ls-files.
Hmm. I don't know... It would make the code rather messy. And are you
really interested in the content stored in the index? In all cases I can
think of, you are better off with a diff vs. working directory or ref.
When I worked with index the first time, I had difficulty knowing what
was in index. Index is, unlike working directory, intangible. I could
use git-diff (and actually did), but it was still better if I could
have seen what exactly was in index.
To me, index and object database are (to some extent) the same: both
are used to store files. If I can examine git object database, why not
index?
About adding index support to git-show, yes it's really messy. index
doesn't have tree objects. If a user wants to list a subdirectory in
index, git-show will have to do more work, I think. Perhaps we should
forget this for now.
--