Re: Commit notes workflow

From: Johan Herland <johan@herland.net>
Date: Jun 14, 2011, 10:15 UTC
Message-ID: <201106141215.50689.johan@herland.net>
In-Reply-To: <20110613090940.664b1b97@chalon.bertin.fr>

On Monday 13 June 2011, Yann Dirson wrote:

> We have notes merge support since a couple of releases now, but no real
> example in the docs of how best to use that.  That is, no suggested
> mapping of remote notes, let alone automatic setup of refspecs at clone
> time.

True. I think this has been held up, partly because I (or anyone else) haven't found the time to work on this, and partly because we want to add some kind of default refspec to easily share notes between repos; the latter has been caught up in the discussion you refer to in [1].

Show 18 quoted lines

> Trying to setup such refspecs, I find myself puzzled:
> 
> * if I store remote notes under refs/notes (eg.
> refs/notes/*:refs/notes/origin/* as fetch refspec), then a
> refs/notes/*:refs/notes/origin/* push refspec will include
> refs/notes/origin/*, which we obviously don't want
> 
> * if I store them outside of refs/notes (eg.
> refs/notes/*:refs/remote-notes/origin/* ), then "git notes" silently
> ignores them: no output nor any error message from "notes list" or
> "notes merge".
> 
> 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)

Show 6 quoted lines

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

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net