On Wednesday 27 January 2010, Junio C Hamano wrote: > Johan Herland <johan@xxxxxxxxxxx> writes: > > The notes feature is still very new, and there are still outstanding > > patches to be merged, but the basics are there in v1.6.6. > > By the way, we should seriously rethink how notes should propagate > through rebases and amends. I've been using this in my post-applypatch > hook lately: > > [...] > > A few observations I made myself so far: > > - I used to fix minor issues (styles, decl-after-stmt, etc.) using > rebase-i long after running "am" in bulk, but these days I find myself > going back to my "inbox" and fix them in MUA; this is only because I > know these notes do not propagate across rebases and > amends---adjusting the workflow to the tool's limitation is not very > good. Agreed. I simply haven't had time to look much into this yet. We should probably add options (both command-line options and config variables) to 'git rebase', 'git commit --amend', 'git cherry-pick', etc. for bringing notes across a commit rewrite. We should probably also add "git notes move/copy <old_object> <new_object>" subcommands to make the same operations available to scripts (and users). > - The interface to tell tools to use which notes ref to use should be > able to say "these refs", not just "this ref" i.e. GIT_NOTES_REF=a:b > just like PATH=a:b:c...); I am fairly certain that we would want to > store different kind of information in separate notes trees and > aggregate them, as we gain experience with notes. Agreed. > - There should be an interface to tell tools to use which notes refs via > command line options; "!alias" does not TAB-complete, and "git lgm" > above doesn't, either. "git log --notes=notes/amlog > --notes=notes/other" would probably be the way to go. Agreed. > - While reviewing the "inbox", I sometimes wonder if I applied a message > to somewhere already, but there is no obvious way to grep in the notes > tree and get the object name that a note is attached to. Of course I > know I can "git grep -c johan@xxxxxxxxxxx notes/amlog" and it will > give me something like: > > notes/amlog:65807ee697a28cb30b8ad38ebb8b84cebd3f255d:1 > notes/amlog:c789176020d6a008821e01af8b65f28abc138d4b:1 > > but this won't scale and needs scripting to mechanize, once we start > rebalancing the notes tree with different fan-outs. The end user (me > in this case) is interested in "set of objects that match this grep > criteria", not "the pathnames the notes tree's implementation happens > to use to store notes for them in the hierarchy". Agreed. Should add a "git notes grep" subcommand. I hope that once the updated notes API is in (I'll send an update to what's in 'pu' shortly), people will have the tools they need to start integrating notes with their pet Git features. As you illustrate perfectly above, there are many corners to be smoothed out before this is well integrated with the other Git tools. 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