Jakub Narebski <jnareb@xxxxxxxxx> 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. > 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. > * "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... - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html