Re: What's cooking in git.git (Sep 2021, #03; Fri, 10)

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

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

>>> * ms/customizable-ident-expansion (2021-09-01) 1 commit
>>>  - keyword expansion: make "$Id$" string configurable
>>>
>>>  Instead of "$Id$", user-specified string (like $FreeBSD$) can be
>>>  used as an in-blob placeholder for keyword expansion.
>>
>> Kinda disappointing to see mis-designs from CVS not only persist but
>> get extended.  Perhaps I'm just biased...
>
> Yeah, if we were doing this today we'd say no, just use a smudge/clean
> filter.
>
> Which is effectively what this feature in git is, i.e. before we had
> that we had this built in smudge/clean filter, but this pre-dates that
> facility.
>
> And yeah, the relevant projects should probably fix their build systems
> to not rely on this CVS-era concept.

So three of us are all unhappy about $Id$, which is sort of
understandable given how long we've been involved in the project.

In one sense, our $Id$ is slightly more useful than CVS's, because
you could detect a non-pristine blob (i.e. take the blob object name
after contracting "$Id:...$" into "$Id$" and if it does not match
what is recorded on "$Id:...$", the blob has been tampered), which
CVS's $Id$ would not help, but it is not a huge advantage.  I'd
rather keep it a low-profile checkbox item whose use is not actively
encouraged.

And then the execution in this topic makes it worse by tying the
customization to the attribute mechanism, which would not fly well
both from usability's point of view (the string $Id$ should not be
per path---or the users need to look up which replacement $Id$
string should be used in a path in .gitattributes) and also
correctness's point of view (when you need to decide if $FreeBSD$ in
a different path need to be replaced, your in-tree .gitattributes
file may have been, or may not yet have been, checked out from the
same source, and the attribute mechanism's notion of "in this path,
$FreeBSD$ is to be replaced, instead of $Id$" may or may not apply).
If it were tied to the normal .gitconfig mechanism, it might have
been slightly more palatable.

> But since we're probably not actually talking about ripping the "$Id$"
> feature out of git & telling users to use their own clean/smudge filter
> or whatever for it, I don't see much harm in that existing facility
> becoming configurable.

See above.  I am OK with configurability via the configuration mechansim,
but not via the attribute subsystem.

>>>  The "--preserve-merges" option of "git rebase" has been removed.
>>>
>>>  Will merge to 'master'.
>>
>> I'm not objecting, but I'm kind of surprised to see this after your
>> and Dscho's previous discussion at
>> https://lore.kernel.org/git/xmqqv939uis8.fsf@gitster.g/; I thought
>> it'd stay in next for a while.  Was this a mistake?
>
> Perhaps I was just really convincing in
> https://lore.kernel.org/git/87fsuedl5x.fsf@evledraar.gmail.com/ ? :)

This is merely a result from a mechanical upgrade of "to 'next'" to
"to 'master'" that happens when the whats-cooking draft gets auto
updated after merging topics to 'next', which probably happened
before the "let's merge and keep" discussion happened.