Re: [PATCH/RFC 1/x] gitweb: Use git-diff-tree patch output for commitdiff

From: Junio C Hamano <junkio@cox.net>
Date: Aug 24, 2006, 02:15 UTC
Message-ID: <7v3bbmhoa2.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200608240015.15071.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

> Converting "blobdiff" and "blobdiff_plain" format would be much easier
> if git-diff-tree and friends had -L <label>/--label=<label> option,
> like GNU diff has.

I am not sure how that would be useful, given that you would disect the header line-by-line to colorize anyway.

Show 5 quoted lines

> Current patch preserves much of current output; the question is if for
> example generate if 'plain' format should generate patch which could
> be appplied by ordinary patch which do not understand git diff
> extensions (including renaming and copying), as it is done in current
> version, and if 'html' version should detect renames and copying.

I would say html is definitely for human consumption; does anybody cut&paste html patch and expect to apply that? Plain format I am easy but probably enabling rename is fine. You can edit the header or tell patch to apply to which file anyway, and I think the value of being able to view the real changes outweigh that inconvenience.

>  * "commitdiff" now products patches with renaming and copying
>    detection (git-diff-tree is invoked with -M and -C options).

You do not have to give -M and -C; a single -C is enough. I wonder if -B is also useful as a default (i.e. -B -C).

For a merge, I often would want to see --cc just like gitk does, but it is probably just me.

I do not know we would want to slurp the entier diff in an array before processing. Is this easy to streamify by passing an pipe fd to the formatting sub?

>    Empty patches (mode changes and pure renames and copying)
>    are not written currently.

That's quite bad.

Show 5 quoted lines

>  * "commitdiff" output is now divided into several div elements
>    of class "log", "patchset" and "patch".
>
>  * "commitdiff_plain" now only generates X-Git-Tag: line only if there
>    is tag pointing to the current commit.

Hmph...

>    ...; besides we are
>    interested rather in tags _preceding_ the commit, and _heads_
>    following the commit.

Interesting observation. When somebody says "feature X was introduced in such and such commit", people would want to know (1) the point release they are using has the feature -- which means you would want to know the earliest tag that comes after the commit, or (2) if the branch they are working on already has that feature -- which again means if the head follows the commit. So I am not sure when preceding tag is interesting...