Re: gitk shows an empty line between "Comments" and changed files

Pavel Roskin [off-list ref] writes:

git-patch-id is only used by git-cherry.  git-cherry writes the second
SHA1 to some files in a temporary directory, but it never reads those
files, it only checks that they exist.

I do not oppose dropping the commit-id line from the default
output, but having it optionally available would be useful in
one application.  Somebody _could_ write a tool that does
something like:

    git-rev-list ^$old_head $new_head |
    git-diff-tree -p -m --stdin --with-commit-ids |
    git-patch-id

to cache the patch-id --> commit-id mappings.  If this were kept
on the upstream repo for public query, it would be useful for
you to find out if your favorite patch as already been merged.
For example, gitweb could have an query page to let you submit a
patch-id and return the commit (or "no such patch merged yet").

Hi, Junio!

On Fri, 2005-10-28 at 02:13 -0700, Junio C Hamano wrote:

Pavel Roskin [off-list ref] writes:

quoted

git-patch-id is only used by git-cherry.  git-cherry writes the second
SHA1 to some files in a temporary directory, but it never reads those
files, it only checks that they exist.

I do not oppose dropping the commit-id line from the default
output, but having it optionally available would be useful in
one application.  Somebody _could_ write a tool that does
something like:

    git-rev-list ^$old_head $new_head |
    git-diff-tree -p -m --stdin --with-commit-ids |
    git-patch-id

Sounds good.  Perhaps the commit IDs should have a prefix identifying
them.

Another approach would be to use something slightly more elaborate than
a pipe.  If I understand correctly, the commit ID would be already known
from the git-rev-list output.  Passing commit IDs through patch-id
without actually doing anything with them seems non-elegant.  Maybe we
could teach git-patch-id (or another script) to get patches by commit-id
instead of using stdin?

-- 
Regards,
Pavel Roskin

On Fri, 28 Oct 2005, Pavel Roskin wrote:

quoted

I do not oppose dropping the commit-id line from the default
output, but having it optionally available would be useful in
one application.  Somebody _could_ write a tool that does
something like:

    git-rev-list ^$old_head $new_head |
    git-diff-tree -p -m --stdin --with-commit-ids |
    git-patch-id

Sounds good.  Perhaps the commit IDs should have a prefix identifying
them.

Guys, why do you want to drop it? We've always had it, and it doesn't 
really hurt.

Yes, gitk got a new empty line because I didn't realize that the output of 
"git-diff-tree $commit" is slightly different from "git-diff-tree $t2 
$t2", but hey, that was due to a gitk change, and I think it should be 
trivial for gitk to just react to it.

So if we add a new flag, please make it go the other way: one that makes 
the output really quiet, but keeps the standard output the same.

		Linus

Pavel Roskin [off-list ref] writes:

quoted

    git-rev-list ^$old_head $new_head |
    git-diff-tree -p -m --stdin --with-commit-ids |
    git-patch-id

Sounds good.  Perhaps the commit IDs should have a prefix identifying
them.

I do not think git-diff-tree -p output can have 40-byte
hexadecimal at the beginning of the output anywhere other than
commit object names; why clutter output?

Another approach would be to use something slightly more elaborate than
a pipe.  If I understand correctly, the commit ID would be already known
from the git-rev-list output.  Passing commit IDs through patch-id
without actually doing anything with them seems non-elegant.

Sorry you lost me.  I am not sure what you mean by "without
actually doing anything" part.  The input to patch-id command in
the above pipe is (commit-object-name patch)*.  The command
reads such a stream, and transforms it to a (patch-id
commit-object-name)* stream.  In other words, the input
identifies each patch with a commit-object-name, and the command
condenses each patch to a patch-id, and spits them out, labelled
with commit-object-name.

On Fri, 28 Oct 2005, Junio C Hamano wrote:

Sorry you lost me.  I am not sure what you mean by "without
actually doing anything" part.  The input to patch-id command in
the above pipe is (commit-object-name patch)*.  The command
reads such a stream, and transforms it to a (patch-id
commit-object-name)* stream.  In other words, the input
identifies each patch with a commit-object-name, and the command
condenses each patch to a patch-id, and spits them out, labelled
with commit-object-name.

Note that git-patch-id will happily take a patch without the commit ID at 
the head, it just won't have a commit ID to match it up with. For such 
patches it will just spit it out with an all-zero commit-object-name.

And that's very much by design. The point is that you can match up your 
(perhaps non-git) patches with what has been accepted. Which is why 
git-patch-id should always take non-git patches too, and then you can 
match them up by sorting by patch ID and doing "join -1" to match up 
duplicates.

So git-patch-id will work with or without the commit ID, but the commit ID 
is then later needed to figure out _which_ commit you matched up.

		Linus

Quoting Linus Torvalds [off-list ref]:

Note that git-patch-id will happily take a patch without the commit ID at
the head, it just won't have a commit ID to match it up with. For such
patches it will just spit it out with an all-zero commit-object-name.

And that's very much by design.

[snip]

OK, if it's by design, I'll fix gitk only.

I understand the default behavior of git-diff-tree won't change, so I'll simply
strip the first line.

--
Regards,
Pavel Roskin

On Sat, 29 Oct 2005, Pavel Roskin wrote:

I understand the default behavior of git-diff-tree won't change, so I'll simply
strip the first line.

Be careful, though. The merge case uses git-diff-tree differently, so I 
think there is no extra line for a merge. 

		Linus

Quoting Linus Torvalds [off-list ref]:

On Sat, 29 Oct 2005, Pavel Roskin wrote:

quoted

I understand the default behavior of git-diff-tree won't change, so I'll

simply

quoted

strip the first line.

Be careful, though. The merge case uses git-diff-tree differently, so I
think there is no extra line for a merge.

Sure.  Thanks.

--
Regards,
Pavel Roskin