Junio C Hamano venit, vidit, dixit 20.01.2010 21:10: > Joey Hess <joey@xxxxxxxxxxx> writes: > >> Do you think it makes sense for even git log --format=format:%s to be >> porcelain and potentially change when new features are used? > > If the series changed the meaning of "%s" format to mean "the subject of > the commit and notes information", with or without documenting it, then it > is just a bug we would like to fix. No, but outputting the note as part of the log is the standard. So for example, when you do a format-patch | apply cycle, format-patch will insert the note as part of the commit message, and apply will *store* the note text (including Note:\n) as part of the commit message of the new commit. So, I would say the notes feature is not that well integrated right now, and either log has to learn --no-notes (and format-patch has to use it, or rather the corresponding internal flag), or apply has to learn to parse "Note:" headers. Or, depending on how you use notes, it may be better if format-patch puts the note after the "--"; that way you can store the usual "after-the-message" patch comments in a note. Similarly, I don't think rebasing and cherry-picking adjust the notes tree for commits with notes whose sha1 changes - which may or may not be the appropriate behaviour. In both cases, the "right" way depends on how you use notes, and there should be an easy way to specify your choice. I'm not complaining, I actually have this on a maybe-to-do list, but the way the series went kept me from investing time. Cheers, Michael -- 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