Re: [PATCH v4] git{,-blame}.el: remove old bitrotting Emacs code

From: Todd Zullinger <tmz@pobox.com>
Date: Apr 18, 2018, 20:16 UTC
Message-ID: <20180418201629.GT29831@zaya.teonanacatl.net>
In-Reply-To: <xmqqa7u83hjd.fsf@gitster-ct.c.googlers.com>

Thanks for working on this cruft cleanup Ævar and to Jonathan & Junio for asking questions about how to improve this transition for packagers & users.

Junio C Hamano wrote:

Show 23 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
>>> On the other hand, the 6-lines of e-lisp you wrote for git.el
>>> replacement is something the packagers could have written for their
>>> users, so (1) if we really want to go extra mile without trusting
>>> that distro packagers are less competent than us in helping their
>>> users, we'd be better off to leave Makefile in, or (2) if we trust
>>> packagers and leave possible end-user confusion as their problem
>>> (not ours), then we can just remove as your previous round did.
>>>
>>> And from that point of view, I find this round slightly odd.
>>
>> I think the way it is makes sense. In Debian debian/git-el.install just
>> does:
>> ...
>> RedHat does use contrib/emacs/Makefile:
>> ...
>> But they can either just do their own byte compilation as they surely do
>> for other elisp packages,...
>
> In short, Debian happens to be OK, but RedHat folks need to do work
> and cannot use what we ship out of the box, *IF* they care about end
> user experience.

I don't think it's a big deal for the Fedora/Red Hat packages to adjust and manually install the stub git-el.

Anyone doing automated rebuilds from the current Fedora git.spec will notice the make failure and can then check the relese notes to find out about the change, I imagine.

> That was exactly why I felt it was "odd" (iow, "uneven").  We bother
> to give a stub git.el; we do not bother to make sure it would keep
> being installed if the packagers do not bother to update their
> procedure.

I wonder if leaving the Makefile in place would prevent packages from even noticing the change? It might still be a good plan to help ease the transition. I don't know if that's as important for something in contrib/ or not.

Show 12 quoted lines

> If we do not change anything other than making *.el into stubs, then
> it is a lot more likely that end user experience on *any* distro
> that have been shipping contrib/emacs/ stuff will by default
> (i.e. if the packagers do not do anything to adjust) be what we
> design here---upon loading they'd see (error) triggering that nudge
> them towards modern and maintained alternatives.  If we do more than
> that, e.g. remove Makefile, then some distros need to adjust, or
> their build would be broken.
> 
> I suspect that the set of people Cc'ed on the thread are a lot more
> familiar than I am with how distro packagers prefer us to deliber,
> so I'll stop speculating at this point.

I should note that I'm not an emacs user, so I likely lack a good understanding of how people use the current git{,-blame}.el files. I could simply be doing it wrong in the steps I took to test this.

With the fedora packaging, we've shipped a git-init.el that adds autoload entries for git-status and git-blame-mode (since adding the emacs files in 2007). That allows users to make use of those features without adding anything to their local emacs configuration.

If I open emacs with a current fedora packaging, I can issue M-x git-status or M-x git-blame-mode. After applying this patch and removing the git-init.el, that no longer works but rather than the detailed warning message, I just get a transient "no matches" in the emacs status line.

However, if I add "(require 'git)" to ~/.emacs, then I get the "error: git.el no longer ships with git" message in the warnings buffer.

Does this mean that only users who have manually loaded git.el will see the warning? If so, is there a preferred method to have the warning appear when calling the commands previously provided, to give a better user experience?

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Faith, n. Belief without evidence in what is told by one who speaks
without knowledge, of things without parallel.
    -- Ambrose Bierce, "The Devil's Dictionary"