mailing list mirror (one of many)
 help / Atom feed
From: Junio C Hamano <>
To: Ævar Arnfjörð Bjarmason <>
Cc:, Alexandre Julliard <>,
	Dorab Patel <>,
	Eric Sunshine <>,
	David Kågedal <>,
	Kyle Meyer <>,
	Martin Ågren <>,
	Ami Fischman <>,
	Jonathan Nieder <>
Subject: Re: [PATCH v4] git{,-blame}.el: remove old bitrotting Emacs code
Date: Thu, 12 Apr 2018 11:19:21 +0900
Message-ID: <> (raw)
In-Reply-To: <>

Ævar Arnfjörð Bjarmason  <> writes:

> However, since downstream packagers such as Debian are packaging this
> as git-el it's less disruptive to still carry these files as Elisp
> code that'll error out with a message suggesting alternatives, rather
> than drop the files entirely[2].
> Then rather than receive a cryptic load error when they upgrade
> existing users will get an error directing them to the README file, or
> to just stop requiring these modes. I think it makes sense to link to
> GitHub's hosting of contrib/emacs/README (which'll be updated by the
> time users see this) so they don't have to hunt down the packaged
> README on their local system.
> ...
>  contrib/emacs/.gitignore   |    1 -
>  contrib/emacs/Makefile     |   21 -
>  contrib/emacs/README       |   32 +-
>  contrib/emacs/git-blame.el |  489 +----------
>  contrib/emacs/git.el       | 1710 +-----------------------------------
>  5 files changed, 25 insertions(+), 2228 deletions(-)
>  delete mode 100644 contrib/emacs/.gitignore
>  delete mode 100644 contrib/emacs/Makefile

I know I am to blame for prodding you to reopen this topic, but I am
wondering if removal of Makefile is sensible.  Is the assumption
that the distro packagers won't be using this Makefile at all and
have their own (e.g. debian/rules for Debian) build procedure, hence
*.el files are all they need to have?

The reason why I am wondering is because I do not know what distro
folks would do when they find that their build procedure does not
work---I suspect the would punt, and end users of the distro would
find that git-el package is no longer with them.  These end users
are whom this discussion is trying to help, but then to these
packagers, the reason why their build procedure no longer works does
not really matter, whether git.el is not shipped, or Makefile that
their debian/rules-equivalent depends on is not there, for them to
decide dropping the git-el package.

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.

  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-03  3:48 [PATCH] git.el: handle default excludesfile properly Dorab Patel
2018-03-03  8:42 ` Eric Sunshine
2018-03-04  1:36   ` Dorab Patel
2018-03-04  2:12     ` Eric Sunshine
2018-03-04  2:57       ` Dorab Patel
2018-03-04  4:34         ` Eric Sunshine
2018-03-05  2:36     ` Junio C Hamano
2018-03-06 11:54       ` Alexandre Julliard
2018-03-07 21:52         ` Dorab Patel
2018-03-08  9:41           ` Ævar Arnfjörð Bjarmason
2018-03-08  9:45         ` [PATCH] git{,-blame}.el: remove old bitrotting Emacs code Ævar Arnfjörð Bjarmason
2018-03-08 17:27           ` Junio C Hamano
2018-03-10 12:30             ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2018-03-10 16:50               ` Martin Ågren
2018-03-13 18:40                 ` Junio C Hamano
2018-03-08 17:55           ` [PATCH] " Kyle Meyer
2018-03-06  4:38 ` [PATCH v2] git.el: handle default excludesfile properly Dorab Patel
     [not found] <>
2018-03-10 18:45 ` [PATCH v3] git{,-blame}.el: remove old bitrotting Emacs code Ævar Arnfjörð Bjarmason
2018-03-13 18:53   ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2018-03-13 22:14     ` Junio C Hamano
2018-03-27 16:57   ` [PATCH v3] " Jonathan Nieder
2018-04-11 20:42     ` [PATCH v4] " Ævar Arnfjörð Bjarmason
2018-04-12  2:19       ` Junio C Hamano [this message]
2018-04-12  6:52         ` Ævar Arnfjörð Bjarmason
2018-04-12  9:23           ` Junio C Hamano
2018-04-18 20:16             ` Todd Zullinger

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox