Re: [ANNOUNCE] Git v2.29.0-rc1

René Scharfe [off-list ref] writes:

Am 12.10.20 um 21:19 schrieb René Scharfe:

quoted

Am 12.10.20 um 18:33 schrieb Junio C Hamano:

quoted

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?

Removing --add-file entirely is certainly possible, but it's used in the
Makefile now and I can't imagine what would make its disposal necessary.

Turning it into a standard OPT_STRING_LIST option for full untracked
paths and using the last --prefix value for all archive entries would be
a more straightforward UI and might be versatile enough.

Here's how that would have looked, but it seems I'm too late.

I think the "unusual --prefix semantics" does not hurt that much.
If people can play funny games, they can, but if they do not want to
confuse themselves, they can just give a single --prefix at the very
beginning (or no --prefix at all of course), and then the semantics
they will get is the same as what this add-on patch gives, I think.

The Makefile rules get a bit more fragile because the version files are
special and the simpler --add-file forces us to create them at their
actual place if not present, which can lead to problems (stuck version)
if we don't delete them afterwards.  Avoiding that was the reason for
the more complicated version that ended up in v2.29.  That fragility
could be defused by teaching GIT-VERSION-GEN about version_is_generated.

Thanks for a thoughtful analysis, as usual.