Re: [ANNOUNCE] Git v2.29.0-rc1

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 26, 2020, 18:01 UTC
Message-ID: <xmqqtuugeujc.fsf@gitster.c.googlers.com>
In-Reply-To: <e135ac82-49f1-e06c-45d7-6b3b9f9837c6@web.de>

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

Show 18 quoted lines

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

Show 6 quoted lines

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