On Friday 05 February 2010, Giuseppe Bilotta wrote:
> On Fri, Feb 5, 2010 at 11:36 AM, Johan Herland wrote:
> > - 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
Yes, that is a possibility, but first we need the infrastructure itself
for doing this.
> > - 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.
Of course.
> > - 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.
Maybe. Making it a git option makes it (GIT_NOTES_REF/--notes-ref)
consistent with things like GIT_WORK_TREE/--work-tree and
GIT_DIR/--git-dir, but then I'm not sure whether notes will affect the
behaviour of enough commands to warrant it becoming a git option.
Consider for example the -m/--message subcommand option which can be
applied to several subcommands (commit, tag, notes, etc.), but that
does not make it a candidate for "promotion" to a git option (i.e.
git -m "foo" commit).
> 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.
Nope. There is no explicit prohibition on anything. On a fundamental
level, Git-notes simply maps a given SHA1 (the annotated object) to
another SHA1 (the object holding the annotation itself). In principle
you can annotate _any_ SHA1, it doesn't even have to exist as a git
object!
In fact, something like the following abomination should solve
your "problem" quite easily:
git notes add $(echo "refs/heads/master" | git hash-object --stdin)
(...washing my hands...)
> 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?
They are no more local than any other ref, except that they are outside
the refspecs that are "usually" pushed/fetched (refs/heads/ and
refs/tags/).
git push <remote> refs/notes/<foo>
git fetch <remote> refs/notes/<foo>[:refs/notes/<foo>]
etc.
should all work as expected.
...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