Re: [ANNOUNCE] Git v2.29.0-rc1

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

René Scharfe <l.s.r@web.de> writes:

> Am 12.10.20 um 21:19 schrieb René Scharfe:
>> Am 12.10.20 um 18:33 schrieb Junio C Hamano:
>>> 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.