Re: [RFC 06/11] Add support for mark references as path names

[Johan Herland <johan@herland.net>]

On Monday 27 July 2009, Shawn O. Pearce wrote:
> Johan Herland <johan@herland.net> wrote:
> > When using a mark reference as a path name, the mark reference will
> > be expanded to the 40-byte hex version of the object name
> > associated with the mark. This is useful e.g. when importing notes
> > objects (where the filenames in a notes tree are the object names
> > of the annotated objects).
> >
> > [...cut...]
>
> I'm worried about changing the path rules here.  Previously writing
> a path as :1 was legal and produced a file named ":1" in the top
> level directory of the repository.  Now it will create a file that
> matches a mark.
>
> I think you need to find another back door, something that the
> language wouldn't have considered as valid previously.

Ok. One (moderately hideous) option is to introduce new commands m/d/r/c 
that works just like M/D/R/C, except that they also expand mark 
references (leaving M/D/R/C with the old behaviour). I don't know how 
you'd feel about that...

However, I'm also pondering Dscho's idea of organizing note trees into 
hierarchies (to limit #entries in tree objects), and (although I have 
yet to try to implement this) it feels like this transformation should 
be done in the notes.c code, which means that it must happen on 
the "git side" of fast-import (at least the transformation should not 
happen on the "external side" of fast-import). This ultimately means 
that we cannot handle notes as "regular" trees and commits (which is 
what I'm trying to do with the help of this patch), and suggests that 
instead of using 'commit' with 'M' for adding notes, we should probably 
have a dedicated 'note' fast-import command that collects note objects, 
and does the tree transformation and subsequent commit upon 
checkpoint/exit.


Have fun! :)

...Johan

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