Subject: Re: [RFC 06/11 v2] fast-import: Add support for importing commit notes

From: "Shawn O. Pearce" <[email-masked]>
Date: Wed, 29 Jul 2009 07:26:34 -0700

Johan Herland <[email-masked]> wrote:
> On Wednesday 29 July 2009, Junio C Hamano wrote:
> > Johan Herland <[email-masked]> writes:
> > > +
> > > +In both formats `<committish>` is any of the commit specification
> > > +expressions also accepted by `from` (see above).
> >
> > Doesn't this make fast-import language incapable of add notes to anything
> > other than commits?  As far as I remember, there is no such limitation in
> > the underlying data structure on git notes, even though the git-notes
> > sample Porcelain might have such a restriction.
> 
> It does (probably because the default notes tree is "refs/notes/commits").

Yea, it does have that limitation right now.  That limitation could
be relaxed in the code by just allowing the <committish> to be any
object and simply don't check its type.

But I've already stated with regards to the notes that I think we
should only allow noting commits and annotated tags, where we have
a timestamp we can use to split the notes in the note tree by time,
so that we can index recent notes much more quickly and can answer
`git log -20` much more efficiently.

I just don't see a lot of value in noting a blob or a tree, there
is too little context information on such things for it to really
be all that useful.

> > We recently hit a similar unintended limitation that we regret in the
> > fast-import language, didn't we?
> 
> I don't know. Must have slipped past my mailbox.

I remember something being raised, but I can't remember exactly
what it was either.

It might have had to do with the effects of rename commands, e.g. a
file rename takes place immediately when issued, and some frontends
wanted it to take place only after the commit was completed.
 
> > Although personally I do not think it is a big deal if we cannot tag or
> > add notes to trees, I am pointing it out in case other people care.
> 
> I copied the semantics from the 'tag' command, for no particular reason 
> (except following the git-notes procelain). Expanding 'notemodify' (and 
> 'tag') to cover all types of objects is fine by me, unless there are good 
> arguments otherwise. Shawn?

tag, there might be arguments for tagging trees, e.g. so you can
export the linux kernel repository with `git fast-export` and reload
it with fast-import.  But that's unrelated to this change.

See above about notes.

-- 
Shawn.