git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Johan Herland <johan@herland.net>
Subject: Re: [PATCH 1/4] gitweb: notes feature
Date: Thu, 4 Feb 2010 21:08:04 +0100	[thread overview]
Message-ID: <cb7bb73a1002041208q54ff1f57y3202e88ae2f5f44e@mail.gmail.com> (raw)
In-Reply-To: <201002041821.22864.jnareb@gmail.com>

On Thu, Feb 4, 2010 at 6:21 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 4 Feb 2010, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>>
>>>> +           my %notes = () ;
>>>> +           foreach my $note_ref (@note_refs) {
>>>> +                   my $obj = "$note_ref:$co{'id'}";
>>>
>>> I think this look-up is wrong (meaning: will stop working anytime in the
>>> future, and needs to be rewritten).
>>
>> IOW, the code should be reading output from:
>>
>>     GIT_NOTES_REF=$note_ref git show -s --format=%N $co{'id'}
>>
>> as the notes tree may not be storing notes in a flat one-level namespace
>> like you are assuming.
>
> First, for some mechanism of deployment (IIRC Apache's mod_perl) changes
> to environment variables from CGI script are not passed to invoked
> commands (I guess for security reasons).  That is why gitweb uses --git-dir
> parameter to git wrapper, and not GIT_DIR environment variable since
> 25691fb (gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'},
> 2006-08-28).  So for proper support we would need --notes-ref (or similar)
> option to git wrapper
>
>  git --notes-ref=$note_ref show -s --format=%N $co{'id'}

As I mentioned on the cover letter, I was hoping to be able to make
something that could be deployable without requiring core changes and
thus a specific minimum git version. I do realize however that this is
inherently not robust (unless the code is updated if and when the
notes storage mechanism changes).

The wrapper is probably needed anyway, I would say, so it makes sense
to implement it. However, see below for a caveat about its
implementation.

> Second, parse_commit / parse_commits use
>
>  git rev-list -z --parents --header --max-count-X
>
> If this command automatically shows notes (or it can be modified to
> automatically show notes) after unindented "Notes:" line (as per
> git-notes documentation), then the only thing that needs to be
> changed to fill %commit{'notes'} is parse_commit_text subroutine.
>
> There would be no need for extra subroutine (and extra command, or
> even up to two extra commands per note) to get notes data.

But unless the --notes-ref is made to accept multiple refspecs, this
will only access _one_ note namespace. It is not hard to envision
situations where multiple namespaces are used for the same repo (e.g.
one to store git-svn metadata, one for bugzilla-related entries), in
which case you'd want _all_ of them to be accessible in gitweb.

And if we do support multiple refspecs for --notes-ref, we also need
some way to identify which note belongs to which namespace, of course,
in any of the output formats that include notes.

An alternative approach would be some git notes-list command that
accepts both multiple namespaces and multiple commits, and is
specifically dedicated to display notes-commits relationships
(together with notes content, obviously)

-- 
Giuseppe "Oblomov" Bilotta

  reply	other threads:[~2010-02-04 20:08 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-04 16:18 [PATCH 0/4] gitweb: preliminary notes support Giuseppe Bilotta
2010-02-04 16:18 ` [PATCH 1/4] gitweb: notes feature Giuseppe Bilotta
2010-02-04 16:33   ` Junio C Hamano
2010-02-04 16:46     ` Junio C Hamano
2010-02-04 17:21       ` Jakub Narebski
2010-02-04 20:08         ` Giuseppe Bilotta [this message]
2010-02-04 21:03           ` Junio C Hamano
2010-02-04 23:38             ` Giuseppe Bilotta
2010-02-05 10:36               ` Johan Herland
2010-02-05 16:10                 ` Junio C Hamano
2010-02-05 21:31                   ` Giuseppe Bilotta
2010-02-05 22:31                   ` Junio C Hamano
2010-02-06  8:16                     ` Giuseppe Bilotta
2010-02-04 21:07         ` Junio C Hamano
2010-02-04 23:20           ` Jakub Narebski
2010-02-05  0:44         ` Jakub Narebski
2010-02-05  0:55           ` Junio C Hamano
2010-02-05  8:42             ` Giuseppe Bilotta
2010-02-05 23:44   ` Jakub Narebski
2010-02-06  9:02     ` Giuseppe Bilotta
2010-02-06 22:14       ` Jakub Narebski
2010-02-06 22:58         ` Giuseppe Bilotta
2010-02-07  1:20           ` Jakub Narebski
2010-02-07  1:38             ` Jakub Narebski
2010-02-07  1:48             ` Johan Herland
2010-02-07 11:08               ` Jakub Narebski
2010-02-07 11:14               ` Giuseppe Bilotta
2010-02-07 12:41                 ` Jakub Narebski
2010-02-07 18:38                   ` Junio C Hamano
2010-02-07 20:11                     ` Giuseppe Bilotta
2010-02-07 21:08                       ` Jakub Narebski
2010-02-07 10:57             ` Giuseppe Bilotta
2010-02-07 11:11               ` Jakub Narebski
2010-02-04 16:18 ` [PATCH 2/4] gitweb: show notes in shortlog view Giuseppe Bilotta
2010-02-06  0:18   ` Jakub Narebski
2010-02-06  9:24     ` Giuseppe Bilotta
2010-02-04 16:18 ` [PATCH 3/4] gitweb: show notes in log Giuseppe Bilotta
2010-02-06 12:57   ` Jakub Narebski
2010-02-06 13:14     ` Giuseppe Bilotta
2010-02-06 21:47       ` Jakub Narebski
2010-02-04 16:18 ` [PATCH 4/4] gitweb: show notes in commit(diff) view Giuseppe Bilotta
2010-02-06 13:16   ` Jakub Narebski
2010-02-06 14:15     ` Giuseppe Bilotta
2010-02-06 14:34       ` Jakub Narebski
2010-02-06 16:13         ` Giuseppe Bilotta
2010-02-06 21:50           ` Jakub Narebski
2010-02-06 22:17             ` Giuseppe Bilotta

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=cb7bb73a1002041208q54ff1f57y3202e88ae2f5f44e@mail.gmail.com \
    --to=giuseppe.bilotta@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=johan@herland.net \
    /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).