Re: Commit notes workflow

On Tuesday 14. June 2011, dirson@bertin.fr wrote:

quoted

quoted

Do we really want to "git notes" to ignore everything not in
 refs/notes/ ? I can think of 2 possibilities out of this
situation:

* remove that limitation
* decide on a naming convention for remote notes, and teach  "git
notes" not to ignore it

The naming convention I have proposed (in the discussion for
[1]) is

refs/notes/*:refs/remotes/$remote/notes/*

(but it obviously depends on reorganizing the entire remote refs
 hierarchy)

quoted

A (minor) problem with the second possibility is that this naming
convention could evolve, eg. if we end up with something like was
proposed in [1] for 1.8.0. Is there any real drawback with  the
first suggestion ?

[1] http://marc.info/?l=git&m=129661334011986&w=4

My gut feeling is to keep some sort of limit notes refs, and
 if/when we get around to implementing my proposal in [1] (or some
variation  thereof), we will of course extend the limit to put
 "refs/remotes/$remote/notes/*" (or whatever is decided) in the
same category as "refs/notes/*".

In the meantime, I'm unsure if it's a good idea to remove the
 limitation altogether (allowing notes refs everywhere), since
re- introducing a limit at a later point will then be MUCH
harder...

So we could introduce something like refs/remote-notes/<remote>/*
today to start working, and eventually phase it out when
refs/remotes/ gets restructured.

Yes, if you can't wait for the refs/remotes/ restructuring, then I guess 
you'll have to do that.

Then the next point will be how best to provide git-pull-like support
for notes refs. We have a number of alternatives, like:

* having "git pull" run "git notes merge" on all notes refs with a
tracking-branch set to the repo from which we pull
* do the same for a configured set of notes refs only
* only have "git pull" and "git status" notify about notes refs being
not uptodate, and add an explicit "git notes pull" command of some
sort (maybe just "git notes merge" without an argument, which would
be consistent with latest "git merge") * surely others

I guess there are a lot of different possibilities here, and there will 
probably be disagreement on what's the best default, so I'd suggest the 
following guidelines:

* make it as configurable as possible.

* follow the existing conventions of pull/merge w.r.t. branches, but 
only so far as it makes sense for notes.

* leave the defaults conservative (e.g. don't do any merging by default, 
but make pull/status notify about update-able notes refs).


My idea so far, is to model the notes configuration on the current 
branch configuration, e.g. something like this:

  [remote "origin"]
      ...
      fetch = +refs/notes/*:refs/remotes/origin/notes/*
      ...

  [notes "commits"]
      remote = origin
      merge = refs/notes/commits

  [notes "bugs"]
      remote = origin
      merge = refs/notes/bugs
      mergeoptions = --strategy=cat_sort_uniq
      automerge = true

Except for the "automerge" option, everything is analogous to current 
branch.<name>.* options. The above configuration sets up a default 
tracking ref for "refs/notes/commits", making

  git notes --ref commits merge

equivalent to

  git notes --ref commits merge refs/remotes/origin/notes/commits

This notes merge would not happen automatically.

The last section, however, would presumably trigger an automatic notes 
merge (on fetch? pull?) because of notes.bugs.automerge being enabled. 
In this case, the

  git notes --ref bugs merge

command would be issued, which would be equivalent to

  git notes --ref bugs merge --strategy=cat_sort_uniq \
      refs/remotes/origin/notes/bugs

This is just a suggestion, and we might want to impose additional 
restrictions not mentioned above. For example, enabling "automerge" 
without enabling a non-"manual" notes merge strategy is probably unwise, 
because it can force the user to resolve conflicts from a notes merge 
that the user did not explicitly initiate.


Have fun! :)

...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net