On Wednesday 29 July 2009, Junio C Hamano wrote: > Johan Herland <johan@xxxxxxxxxxx> writes: > > +External data format:: > > + The data content for the note was already supplied by a prior > > + `blob` command. The frontend just needs to connect it to the > > + commit that is to be annotated. > > ++ > > +.... > > + 'N' SP <dataref> SP <committish> LF > > +.... > > ++ > > +Here `<dataref>` can be either a mark reference (`:<idnum>`) > > +set by a prior `blob` command, or a full 40-byte SHA-1 of an > > +existing Git blob object. > > + > > +Inline data format:: > > + The data content for the note has not been supplied yet. > > + The frontend wants to supply it as part of this modify > > + command. > > ++ > > +.... > > + 'N' SP 'inline' SP <committish> LF > > + data > > +.... > > ++ > > +See below for a detailed description of the `data` command. > > + > > +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"). > 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. > 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? Have fun! ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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