blameview and file contents

Hi,

I guess blame view need to pull the file content from the repository
rather than opening it directly. If i have a working copy that is not
yet committed it gives wrong results. I tried some changes as below.
But i guess there should be a much easier way.

-aneesh

Aneesh Kumar [off-list ref] wrote:

I guess blame view need to pull the file content from the repository
rather than opening it directly. If i have a working copy that is not
yet committed it gives wrong results. I tried some changes as below.
But i guess there should be a much easier way.

-open(my $fh, '<', $fn)
-  or die "unable to open $fn: $!";
+$fh = get_file_handle("HEAD", $fn);
 while(<$fh>) {
   chomp;
   $fileview->{data}->[$.] = ['HEAD', '?', "$fn:$.", $_];

Doesn't the following work just as well, and use a lot less code?

  open(my $fh, '|-', 'git', 'cat-file', 'blob', "HEAD:$fn")

?

-- 
Shawn.

On 1/30/07, Shawn O. Pearce [off-list ref] wrote:

Aneesh Kumar [off-list ref] wrote:

quoted

I guess blame view need to pull the file content from the repository
rather than opening it directly. If i have a working copy that is not
yet committed it gives wrong results. I tried some changes as below.
But i guess there should be a much easier way.

quoted

-open(my $fh, '<', $fn)
-  or die "unable to open $fn: $!";
+$fh = get_file_handle("HEAD", $fn);
 while(<$fh>) {
   chomp;
   $fileview->{data}->[$.] = ['HEAD', '?', "$fn:$.", $_];

Doesn't the following work just as well, and use a lot less code?

  open(my $fh, '|-', 'git', 'cat-file', 'blob', "HEAD:$fn")

?

See i said that there should be a simple way. Can we get this
documented in git-cat-file man page

-aneesh

Aneesh Kumar [off-list ref] wrote:

See i said that there should be a simple way. Can we get this
documented in git-cat-file man page

Well, this isn't the git-cat-file man page, but we do suggest people
use `git show HEAD:foo.c` to get foo.c from HEAD in an interactive
setting.  The git-show manpage refers people to git-rev-parse,
which has the following:

	* A suffix ':' followed by a path; this names the blob or tree
	  at the given path in the tree-ish object named by the part
	  before the colon.

In a non-interactive case, well, that's what git-cat-file is for.
And <object> typically is meant to mean what git-rev-parse will
parse... 

But if you submit a documentation update to git-cat-file's manpage
that points off to the same section of git-rev-parse, folks may
appreciate it.  :-)

-- 
Shawn.