On Friday 05 February 2010, Giuseppe Bilotta wrote:
> On Thu, Feb 4, 2010 at 10:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > I expect more ideas from needs by end-user would come, as we gain
> > experience with using notes in real projects. You will certainly find
> > some other needs of your own, like the "not an environment but a
> > command line option" which Jakub mentioned, and "multiple hierarchies"
> > like both you and I found need for. Share them and let us together
> > make the notes mechanism nicer to use.
>
> Collecting those ideas together would also help define some sort of
> roadmap, or at least have a clear idea of what's needed, to help drive
> the design of the features themselves. Maybe we could start a TODO
> page on the wiki collecting these ideas?
I already maintain a TODO list at the end of the cover letter to the notes
series. Here is a preview of it (I plan to send the next iteration of
jh/notes as soon as v1.7.0 is released):
- Suggestion by Matthieu Moy and Sverre Rabbelier:
Add notes support to git-format-patch, where note contents in
refs/notes/format-patch are added to the "comments section"
(i.e. following the '---' separator) of generated patches.
- Better integration with rebase/amend/cherry-pick. Optionally bring
notes across a commit rewrite. Controlled by command-line options
and/or config variables. Add "git notes move" and "git notes copy"
to suit. Junio says:
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.
- Junio says:
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.
- Junio says:
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.
- Add a "git notes grep" subcommand: Junio says:
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".
- Handle note objects that are not blobs, but trees
(- Rewrite fast-import notes code to use new notes API with non-note
support)
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