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). > > Signed-off-by: Johan Herland <johan@xxxxxxxxxxx> > --- > Documentation/git-fast-import.txt | 9 +++++++-- > fast-import.c | 11 +++++++++-- > 2 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt > index c2f483a..bbc8b78 100644 > --- a/Documentation/git-fast-import.txt > +++ b/Documentation/git-fast-import.txt > @@ -487,12 +487,17 @@ in octal. Git only supports the following modes: > > In both formats `<path>` is the complete path of the file to be added > (if not already existing) or modified (if already existing). > +`<path>` may also be a mark reference (`:<idnum>`) set by a prior > +command, which will expand to a full 40-byte SHA-1 of the Git object > +associated with the mark. This is useful e.g. when importing commit > +notes (the filenames in a notes commit are the object names of the > +annotated commits). > > A `<path>` string must use UNIX-style directory separators (forward > slash `/`), may contain any byte other than `LF`, and must not > -start with double quote (`"`). > +start with double quote (`"`) or colon (`:`). 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. -- Shawn. -- 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