On Monday 27 July 2009, Shawn O. Pearce wrote: > Johan Herland <johan@xxxxxxxxxxx> 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@xxxxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html