Re: Commit notes workflow

From: Johan Herland <johan@herland.net>
Date: Jun 14, 2011, 14:41 UTC
Message-ID: <201106141641.14257.johan@herland.net>
In-Reply-To: <f81891b81d39.4df76a5c@bertin.fr>

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

Show 37 quoted lines

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

Show 10 quoted lines

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