On Wednesday 17 February 2010 20:59:26 Johannes Sixt wrote:
> I think that this form of --notes-filter is not flexible enough.
> 
> 1. There is no possibility for the filter to decide whether the note 
> should be attached to the rewritten commit or not.

That's not 100% correct, but it's not your fault for not knowing: if
you add an empty note, that's the same as removing it.

> 2. The implementation is not concerned about different notes namespaces 
> (IIUC).
> 
> 3. There is probably more.
> 
> One use-case that comes to mind is to move notes from one particular 
> namespace to a different one (and I mean move, not just copy). Don't know 
> if 'git notes' itself has such a feature.
> 
> I am not a 'git notes' user at this time, nor do I know anything about the 
> implementation, nor did I follow any discussions about notes, hence, I'm 
> not in the position to judge what --notes-filter could be useful
> for.

I'm currently leaning towards declaring this the realm of
--post-rewrite, not --notes-filter.  I'm not saying that the former is
the perfect / most convenient format in which such a hook could be
specified, but I believe its input should just be pre and post rewrite
sha1.  Using it to move notes, or whatever, should be up to the user.

That's not to say that there shouldn't be some convenient interface to
manage several notes trees, which I'm not yet clear on.

> I know I talked you into implementing it, but that is just because I dislike 
> that filter-branch calls a post-rewrite hook (that just doesn't sound 
> right to me, given the one-shot nature of filter-branch), and your 
> intention obviously was to transfer notes.

No (as I said in the original series leader) my original motivation
was to have a hook that can record the pre-write sha1 in a note on the
rewritten commit.  I noticed that it could also be used to transfer
the notes to the rewritten commit, which was part of the reason why I
implemented it.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch