git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Cc: git@vger.kernel.org
Subject: Re: Supporting more gitweb diff possibities
Date: Mon, 26 Mar 2007 18:11:38 +0100	[thread overview]
Message-ID: <200703261911.39328.jnareb@gmail.com> (raw)
In-Reply-To: <20070325202642.GA20201@auto.tuwien.ac.at>

On Sun, Mar 25, 2007, Martin Koegler wrote:

> I have done a first series of 6 patches, which improves blobdiff and
> adds treediff.

Just a few nits.

First, I think it would be better to have individual patches to be
replies to this cover letter, either directly (all patch mails
are replies to cover letter) or indirectly (i.e. chained, the later
patch is reply to earlier patch, first patch ir reply to cover letter).

Second, it is a good idea to _number_ patches in series, i.e. have
  "[PATCH 0/6] Supporting more gitweb diff possibities"
as cover letter subject, and number patches respectively. The option
`-n' of git-format-patch (together with --start-number if you make
patches one by one) takes care of that.

> [PATCH] gitweb: show no difference message

This should be I think: 
  "[PATCH 1/6] gitweb: show "no difference" message for empty diff"

> This patch shows an "no difference" message instead of nothing for
> equal objects.

This is a good patch, worth doing even without rest of the patches.

Currently we have only one place (I think) where gitweb can generate
link to "blobdiff", namely "diff to parent" link in "history" view
for plain file, when e.g. some change was (explicitely or accidentally)
reverted.

The few comments about style (variable naming, CSS style for 
"no differences" message) are in the reply to the patch.

> [PATCH] gitweb: Support comparing blobs with different names
> 
> This patch adds support for comparing objects with different file
> names using hb/hbp.

Good idea; I have replied with an alternate solution, involving adding
'fp' to git-diff-tree path limit instead of git-diff with hpb:fp.

I'm sorry for the confusing advice wrt. git_blobdiff and rename diffs.

> [PATCH] gitweb: link base commit (hpb) to blobdiff output
> 
> Add link the parent commit, as there is currently no such link.

I'm rather ambivalent about this patch. Perhaps there is currently no such
link, but you can always click on one of the links to parent blob, and
from blob view to commit, commitdiff or tree.

By the way, the "(from: _commitdiff_)" link in "commitdiff" view
(and similar one in "commit" view) is part of the "next link" family
of "(parent: _commitdiff_)" and "(merge: _commitdiff_ _commitdiff_)"
which allow to go down the line of parents without need to change
views (or go to the 'parent' header in the case of "commit" view),
just like you would press PageDown during "git log" or "git log -p"
invocation from the command line. "(from: _commitdiff_)" was added
only for completeness (and because it was easy to do).

> [PATCH] gitweb: support filename prefix in git_patchset_body
> [PATCH] gitweb: support filename prefix in git_difftree_body

I'm not sure if those patches should or should not be concatenated
together in one commit.

See further comments on style (variable naming) and alternate solution
in the comments to first patch of those two: they refer to both patches.

> [PATCH] gitweb: Add treediff

Shouldn't it be:
  "[PATCH 6/6] gitweb: Add "treediff" and "treediff_plain" views"

> These 3 patches add the treediff method. Its a complete reworked
> verion. As git-diff-tree outputs relative patches (discards part of the
> compared tree objects), the first two patches are necessary to produce
> correct links in the treediff output.

See comments for that patch.

> I do not see many possibilties for code sharing with git_commitdiff:
> The only large portion of common code is calling git-diff-tree. I
> don't think that this would justify the more complex code.

I was not thinking about using git_commitdiff to generate "treediff"
view, but rather about extracting the common code into separate subroutine.
But it might (or might not) be not worth the hassle. And it can always
be done in separate "refactoring" patch.

-- 
Jakub Narebski
Poland

      reply	other threads:[~2007-03-26 17:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-25 20:26 Supporting more gitweb diff possibities Martin Koegler
2007-03-26 17:11 ` Jakub Narebski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200703261911.39328.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mkoegler@auto.tuwien.ac.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).