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

From: Johan Herland <johan@herland.net>
Date: Feb 5, 2010, 14:46 UTC
Message-ID: <201002051546.19406.johan@herland.net>
In-Reply-To: <cb7bb73a1002050444y55f57696gb1b3bd06ab9261ac@mail.gmail.com>

On Friday 05 February 2010, Giuseppe Bilotta wrote:

Show 17 quoted lines

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

Show 11 quoted lines

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

Show 9 quoted lines

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

Show 7 quoted lines

> 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@herland.net>
www.herland.net