Re: [ANNOUNCE] Git v2.29.0-rc1

[Junio C Hamano <gitster@pobox.com>]

René Scharfe <l.s.r@web.de> 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?