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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sep 11, 2021, 17:42 UTC
Message-ID: <87k0jn80np.fsf@evledraar.gmail.com>
In-Reply-To: <CABPp-BGR3dfJE7TZ+jkjDdWyeXYowmJhtoFaQ8_Abn=ZROhB5Q@mail.gmail.com>

On Sat, Sep 11 2021, Elijah Newren wrote:

Show 18 quoted lines

> On Fri, Sep 10, 2021 at 3:12 PM Junio C Hamano <gitster@pobox.com> wrote:
> [...]
> I just sent a reroll, since I did have some fixes from Phillip and
> some new testcases, but it fails one of the testcases I made and I saw
> another suboptimal case that I lost but would like to include.  I
> still have this labelled RFC and it's definitely not ready.
>
> I do plan to get back to it eventually, but am focusing more on other
> topics, so you may want to eject this from seen for now.
>
>> * 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.

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.

Show 22 quoted lines

>> * js/retire-preserve-merges (2021-09-07) 11 commits
>>   (merged to 'next' on 2021-09-10 at f645ffd7a3)
>>  + sequencer: restrict scope of a formerly public function
>>  + rebase: remove a no-longer-used function
>>  + rebase: stop mentioning the -p option in comments
>>  + rebase: remove obsolete code comment
>>  + rebase: drop the internal `rebase--interactive` command
>>  + git-svn: drop support for `--preserve-merges`
>>  + rebase: drop support for `--preserve-merges`
>>  + pull: remove support for `--rebase=preserve`
>>  + tests: stop testing `git rebase --preserve-merges`
>>  + remote: warn about unhandled branch.<name>.rebase values
>>  + t5520: do not use `pull.rebase=preserve`
>>
>>  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/ ? :)