René Scharfe <l.s.r@xxxxxx> writes:
> The option --add-file in rc1 is peculiar in that it captures the value
> of --prefix at the time of left-to-right parsing. I don't know any
> other option that does that.
If you do not count the early design of "git update-index", where
you could do funky things like
git update-cache must-exist --add new-file
to affect the way each path argument is taken, that is ;-)
I am not sure if that is a useful feature, but I do not see a reason
to add more code just to forbid giving the prefix argument multiple
times. As the main archive contents taken out of tree use just the
single "--prefix", I suspect nobody would even imagine giving
multiple "--prefix".
> It gives users a way to craft in-archive
> paths, but simply adding them with their original path (just normalized
> to use slashes as directory separators) would probably suffice.
>
> The option serves a niche use case, so this weirdness might be bearable,
> but I wouldn't have expected it to be merged without debate. Perhaps
> we want to slap an "experimental" label on it?
I have no strong opinion on this.
If this "feature" were experimental and if the experiment turns out
to be a failure, would we have a viable alternative definition?
Perhaps "--add-file names an untracked file in the working tree and
the single '--prefix' that is used for entries that come from the
tree object is applied"? Or perhaps remove --add-file entirely as a
failed experiment?
