Re: Git notes list/show <revision-range>

[Michael J Gruber <git@drmicha.warpmail.net>]

Jeff King venit, vidit, dixit 19.04.2011 22:32:
> On Tue, Apr 19, 2011 at 09:17:51AM +0200, Michael J Gruber wrote:
> 
>> But since the OP is volunteering to code for notes :-)
>> We could need a feature which allows to log the history of a note. The alias
>>
>> `git noteslog' is aliased to `!sh -c 'git log $(git notes get-ref) "$@"' -'
>>
>> gives you the history of the notes tree (try it with "-p"),
> 
> Hmm, I just use "git log notes/<whatever>", which works fine. It does
> help if you know that the default ref is "notes/commits", though.

Sure. That's what the alias does.

> It's not something I do often, though (most of my notes use has been
> things that automatically make notes, so the history tends to be
> uninteresting and useful only for debugging the note-making code).

In particular, the log messages "Notes added by..." are useless. I use
notes for patch boiler plates and branch annotations, and in these cases
history can be interesting (between versions of a patch, e.g.).

>> sometimes I would like the history of the notes to a specific commit, and in
>>
>> git noteslog -p -- $(commit)
>>
>> I would have to use for $(commit) all possible breakdowns of the sha1 of
>> the commit for all possible notes tree structures. It feels as of the
>> revision walker needs to learn another pathspec, say
>>
>> ":(note):<sha1>"
>>
>> in line with our magic pathspec discussion.
> 
> That's a clever solution. It is a little non-intuitive for a user to
> need to know about notes storage, though. Maybe you were already
> thinking this, but we could have something like:
> 
>   git notes log [revs] [--] [pathspec]
> 
> where "[revs]" are checked for in refs/notes/*, defaulting to
> "refs/notes/commits". And each element of the pathspec gets the
> ":(note):" magic automatically. I wonder if we could even resolve the

Here we are back at my alias is a first step in that direction... "git
notes log" should do all that, of course.

> pathspec bits as regular refs.
> 
> So you could write:
> 
>   # long form, just as you can do with "git log"
>   git notes log notes/commits -- ":(note):`git rev-parse HEAD`"

I don't think "notes log" should take a notes ref argument like that. It
already has "--ref" for that purpose, so I would suggest

git notes [--ref <notesref>] log [<rev>]

with <rev> being mapped to :(notes):<rev> automatically, <rev>
defaulting to HEAD. That is much more in line with the other notes
subcommands. (We may or may note check for ":(notes):" being there already.)

> 
>   # or with automagic ref lookup for pathspec
>   git notes log notes/commits -- HEAD
> 
>   # and automagic default ref
>   git notes log -- HEAD
> 
>   # and I think you should be able to write a disambiguator similar to
>   # what we use for the revs/paths distinction, but this time for
>   # notes-refs versus regular refs. And then drop the "--":
>   git notes log HEAD
> 
> I think it would need a little refactoring of setup_revisions() to be
> more flexible, but most of the hard work is already done by the usual
> revision traversal mechanism.

? I haven't checked in detail, but I think all we need is:

- Make "git notes --ref <notesref> log <rev>" call "git log
<resolvednotesref> -- :(notes):<rev>" (and pass on log options).

- Make the pathspec ":(notes):<rev>" resolve <rev> to <sha1> and match
with all possible breakdowns of <sha1> which we accept for a notes tree.

Michael