notes TODOs (was: Re: [PATCH 1/4] gitweb: notes feature)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 5, 2010 at 11:36 AM, Johan Herland <johan@xxxxxxxxxxx> wrote:
>
> 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.

It might be useful to this purpose to have a notes.<refname>.* config
space, like for branches. This would allows us to define per-namespace
attribute for notes, such as whether or not they get across rebases,
whether or not (and how) they are output in format-patch, in logs, etc

> - 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.

I would say that this only makes sense when reading notes, since when
you are writing a note you probably want to add it to a single
specific namespace.

For multiple refs I was thinking about shell expansion patterns, with
syntax such as {a,b} rather than a:b; even shell globs might make
sense (so e.g. * would mean 'all existing notes ref namespaces', bug*
all namespaces starting with bug, etc).

Of course the use of multiple namespaces also means that users
(whether human or script) need to be able to teel which namespace each
note comes from.

> - 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.

As mentioned elsewhere in this thread, this might be better as a git
option rather than a subcommand option: git --notes-ref=amlog:other
log or git --notes-ref={amlog,other} log.

If I may be allowed to add a suggestion to put in the list, I would
like to see notes attachable to named refs (branch heads in
particular). From a cursory reading of your patches currently in pu it
would seem that you explicitly prohibit this case currently. However,
this has many possible uses, ranging from longer branch descriptions
to tracking information to improve survival in case of remote rebases.

And one last comment: how do notes behave wrt to cloning and remote
handling? Am I correct in my understanding that notes are (presently)
local only? Would it make sense to have them cloned to something like
the refs/notes/remotes/* namespace?





-- 
Giuseppe "Oblomov" Bilotta
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]