Giuseppe Bilotta [off-list ref] writes:
As I mentioned on the cover letter, I was hoping to be able to make
something that could be deployable without requiring core changes and
thus a specific minimum git version. I do realize however that this is
inherently not robust (unless the code is updated if and when the
notes storage mechanism changes).
AFAIU, the note code on the core side already creates a fan-out structure
when notes tree gets large (see recent "What's cooking"; the series is
parked in 'pu' but that is primarily because we are in feature freeze); it
is not just "inherently not robust" but is much closer to "broken from day
one" ;-). Otherwise I wouldn't have wasted time to point it out.
Your code is a very good proof-of-concept, though.
Regarding support of multiple notes hierarchies, listing, etc.
See for example:
http://thread.gmane.org/gmane.comp.version-control.git/138079/focus=138128
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.
Thanks.
On Thu, Feb 4, 2010 at 10:03 PM, Junio C Hamano [off-list ref] wrote:
AFAIU, the note code on the core side already creates a fan-out structure
when notes tree gets large (see recent "What's cooking"; the series is
parked in 'pu' but that is primarily because we are in feature freeze); it
is not just "inherently not robust" but is much closer to "broken from day
one" ;-). Otherwise I wouldn't have wasted time to point it out.
Ouch, I hadn't considered that, indeed.
Your code is a very good proof-of-concept, though.
Thanks. I guess at this point a proper implementation can wait for the
necessary core support functions.
Regarding support of multiple notes hierarchies, listing, etc.
See for example:
http://thread.gmane.org/gmane.comp.version-control.git/138079/focus=138128
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?
--
Giuseppe "Oblomov" Bilotta
On Friday 05 February 2010, Giuseppe Bilotta wrote:
On Thu, Feb 4, 2010 at 10:03 PM, Junio C Hamano [off-list ref] wrote:
quoted
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@herland.net 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, [off-list ref]
www.herland.net