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

["Shawn O. Pearce" <spearce@spearce.org>]

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).
> 
> Signed-off-by: Johan Herland <johan@herland.net>
> ---
>  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.