Re: [ANNOUNCE] Git v2.29.0-rc1

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 12, 2020, 16:33 UTC
Message-ID: <xmqqmu0rqu8h.fsf@gitster.c.googlers.com>
In-Reply-To: <ce8f482f-9a78-6867-38ae-601bcc2c9f66@web.de>

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".

Show 7 quoted lines

> 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?