gmane.comp.version-control.git.magit

Re: Bug#671922: magit: Does not autoload extensions

Timo Juhani Lindfors — 2012-05-21T15:39:03

package magit
tags 671922 pending
thanks

Hi,

Rémi Vanicat <remi.vanicat-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> writes:

Thanks for the idea! I spent a while looking at emacs documentation and
came up with a similar solution. Preliminary packages are available at

http://iki.fi/lindi/magit/debian/

and will be uploaded next weekend unless major issues are found. I also
pushed the updated packaging to

http://anonscm.debian.org/gitweb/?p=collab-maint/magit.git

Braun Gábor, can you test the packages?

magit (1.1.1-2~try1) UNRELEASED; urgency=low

  * Backport upstream commit c8cfaf37b7c142edc6714d86691b8720f2606328
    for autogenerating autoloads (closes: #671922).
  * Bump Standards-Version to 3.9.3 (no changes needed).
  * Update upstream homepage URL.
  * Remove DM-Upload-Allowed.

 -- Timo Juhani Lindfors <timo.lindfors-X3B1VOXEql0< at >public.gmane.org>  Mon, 21 May 2012 14:35:24 +0000

Re: Bug#671922: magit: Does not autoload extensions

Rémi Vanicat — 2012-05-15T18:31:19


Well one could rename the upstream 50magit.el to
/usr/share/emacs/site-lisp/magit/magit-install.el and load it from the
/etc/emacs/site-start.d/50magit.el, for example by doing:

--8<---------------cut here---------------start------------->8---
;;; load magit autoloads
(if (member debian-emacs-flavor '(emacs23 emacs-snapshot))
    (let ((package-dir (concat "/usr/share/"
                               (symbol-name debian-emacs-flavor)
                               "/site-lisp/magit")))

      ;; If package-dir does not exist, the org-mode package must have
      ;; removed but not purged, and we should skip the setup.
      (when (file-directory-p package-dir)
        (debian-pkg-add-load-path-item package-dir)
        (load "/usr/share/emacs/site-lisp/magit/magit-install.el"))))
--8<---------------cut here---------------end--------------->8---

Re: Bug#671922: magit: Does not autoload extensions

Timo Juhani Lindfors — 2012-05-15T10:29:02

The org-mode debian package has 

;; -*-emacs-lisp-*-
;;
;; Emacs startup file, e.g.  /etc/emacs/site-start.d/50org-mode.el
;; for the Debian org-mode package
;;
;; Originally contributed by Nils Naumann <naumann-wOwGiPSyfOJL76+I05PHkQ< at >public.gmane.org>
;; Modified by Dirk Eddelbuettel <edd-8fiUuRrzOP0dnm+yROfE0A< at >public.gmane.org>
;; Adapted for dh-make by Jim Van Zandt <jrv-8fiUuRrzOP0dnm+yROfE0A< at >public.gmane.org>

;; The org-mode package follows the Debian/GNU Linux 'emacsen' policy and
;; byte-compiles its elisp files for each 'emacs flavor' (emacs19,
;; xemacs19, emacs20, xemacs20...).  The compiled code is then
;; installed in a subdirectory of the respective site-lisp directory.
;; We have to add this to the load-path:
(let ((package-dir (concat "/usr/share/"
                           (symbol-name debian-emacs-flavor)
                           "/site-lisp/org-mode")))

;; If package-dir does not exist, the org-mode package must have
;; removed but not purged, and we should skip the setup.
  (when (f

Re: editor help to properly format git commit messages

PJ Weisberg — 2012-05-12T23:55:33

There is a git-commit-mode out there.  There was some discussion about
integrating it into Magit[1], but nothing ever came of it.

It's already fairly easy to maintain those standards in Emacs, if one
is interested in maintaining those standards.  Wrapping the lines in a
paragraph is as easy as pressing M-q.

[1] https://groups.google.com/group/magit/browse_thread/thread/2cca7dd1f3e65433/92ee88ba7add2b8c

-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

editor help to properly format git commit messages

Eric Schulte — 2012-05-12T19:24:31

Hi,

In the following recent diatribe [1] Linus Torvalds shares a number of
rules for properly formatting git commit messages including.
- each commit should start with a short, single-line, <=50 char summary
  followed by an empty line
- every other line should be <=72 chars (excepting non-prose, like
  compiler output)

Should magit add editor support for maintaining these standards in the
log-edit buffer?  The magit-log-edit-mode-hook already exists which
could be used to do this in ones personal configuration.  Has anyone
done this who would be willing to share their setup?

Thanks,

Footnotes: 
[1]  https://github.com/torvalds/linux/pull/17#issuecomment-5654674

Re: OT: gmane address mangling selectors

Eli Barzilay — 2012-05-10T17:35:52

IIRC, gmane intercepts a first-time post to a newsgroup->mailing list
using a mangled email that it gets and later forwards on your behalf
when you prove that you're human.  Or something like that.  The weird
thing is that it did that for a personal email -- maybe someone posted
a reply with CCs, where the usual thing is to have only newsgroups?

OT: gmane address mangling selectors

Jeff King — 2012-05-10T17:19:12


Ah, I never got that message. Probably because...


...I have no clue where that address would end up.


Where do they come from? I notice that my address has been mangled
above, but I do not use gmane to either post or read the list. In fact,
looking at the start of the thread in my mailbox, I see:

  1. Eli posts[1], to: git< at >vger and magit< at >googlegroups; his from address
     looks normal, and there is no reply-to.

  2. You reply, to: a gmane-mangled address, cc: git< at >vger.

The presence of the magit list is obviously the unusual thing here, but
he did not involve gmane at all. If I recall correctly, you read the
list via gmane. So I believe it is your workflow that introduces the
mangled addresses on the reading end, not the sender.

It seems that this gmane "feature" is turned on by the presence of the
magit list, which I guess is configured at gmane to obfuscate emails.
But I don't see how the sender should be expected to know or care about
this gmane nonsense. It is your fault that the gateway through

Re: [PATCH 4/4] reflog-walk: always make HEAD< at >{0} show indexed selectors

Junio C Hamano — 2012-05-10T16:39:44


Heh, it was sent before I gave you this message:

        From: Junio C Hamano <gitster-e+AXbWqSrlAAvxtiuMwx3w< at >public.gmane.org>
        Subject: Re: [PATCH 4/4] reflog-walk: always make HEAD< at >{0} show indexed selectors
        To: Jeff King <peff-AdEPDUrAXsQ-XMD5yJDbdMReXY1tMh2IBg< at >public.gmane.org>
        Date: Mon, 07 May 2012 14:54:24 -0700

        Jeff King <peff-AdEPDUrAXsQ-XMD5yJDbdMReXY1tMh2IBg< at >public.gmane.org> writes:

        > I think some of the callers set dmode to DATE_NORMAL explicitly. So this
        > code would be confused into thinking that the user had asked for it
        > explicitly. Or maybe it happens before the date_mode_explicit check, and
        > it would be OK. I'd have to do audit the code.

        Yeah, that is why today's update I sent does not use DATE_DEFAULT, which
        is after all a hack to piggy-back logically a separate bit in the same
        variable.  What we are trying to tell these two functions are (1) does the
        caller prefer to use counted notati

Re: [PATCH 4/4] reflog-walk: always make HEAD< at >{0} show indexed selectors

Jeff King — 2012-05-10T15:37:54


I just took a look at what you built on top of this topic (55ccf85)
instead of the bit quoted above. I also found it ugly not to pass the
explicit flag all the way down to the point-of-use. I had a nagging
feeling that the original did not do it that way for some good reason,
but looking at your patch, I cannot fathom what that reason could
possibly be. So it looks good to me.

-Peff

PS It would have been nice to see the patch on the list for review. I
   only noticed it because it hit 'next', and had a minor conflict with
   my patches in the area.

Re: Bug#671922: magit: Does not autoload extensions

Rémi Vanicat — 2012-05-08T16:13:24


There is the org-install.el file of org-mode (I don't know if it is used
by the Debian package, but I know that this file play a similar role
than 50magit.el, and is generated in similar way).

Re: Bug#671922: magit: Does not autoload extensions

Timo Juhani Lindfors — 2012-05-08T12:37:37

No idea. I went through several emacs extensions in debian and could not
find anything that'd be similar to what the code in git autogenerates.

Re: Bug#671922: magit: Does not autoload extensions

Yann Hodique — 2012-05-08T12:18:18



Ok, so I guess worst case you can generate a Debian-specific one that
may or may not load this one.

Actually I'm not even sure exactly why we generate this one in the
first place. Do some of our users explicitly load it ?

Yann.

Re: Bug#671922: magit: Does not autoload extensions

Timo Juhani Lindfors — 2012-05-08T11:34:32

Good question. In general the autoload file is written in a distribution
specific way and not inherited from upstream.

Re: Bug#671922: magit: Does not autoload extensions

Yann Hodique — 2012-05-08T10:50:53




Sorry, I'm not familiar with the Debian policy. Is there something that
needs to be fixed on our side ?
I mean *without* referring to things like `debien-emacs-flavor', that are
meaningless outside of Debian :)

Yann.

Re: Bug#671922: magit: Does not autoload extensions

Yann Hodique — 2012-05-08T10:44:46








I just backported the fix to the 'maint' branch, so it'll be fixed in
1.1.2

Thanks,

Yann.

Re: Bug#671922: magit: Does not autoload extensions

Timo Juhani Lindfors — 2012-05-08T10:42:14

Hmm. "make" in git master generates a really long 50magit.el. My problem
is that this file does not comply with the debian emacs policy. magit
stuff should only be autoloaded if debian-emacs-flavor is emacs23 or
emacs-snapshot and if the package is installed:

(if (member debian-emacs-flavor '(emacs23 emacs-snapshot))
    (if (file-exists-p "/usr/share/emacs/site-lisp/magit/magit.el")
        (autoload 'magit-status "magit" nil t)
      (message "Package magit removed but not purged. Skipping setup.")))

Re: Bug#671922: magit: Does not autoload extensions

Yann Hodique — 2012-05-08T10:18:09





Hi,

this is indeed a bug.
The problem is that 50magit.el has not been properly updated. If you
instead install magit via package.el instead, you would see that
extension code is autoloaded properly.

The proper fix is to generate this file (which is fixed in the 'master'
git branch but didn't hit any release yet).

magit-simple-keys.el is a totally different problem, as it's not part of
magit itself (only a convenient contrib). So in any case, it will have
to be loaded manually (on purpose).

Yann.

Re: Bug#671922: magit: Does not autoload extensions

Timo Juhani Lindfors — 2012-05-08T08:08:53

Hi,

[ Sending a copy to upstream mailing list for further comments ]

I'm bit puzzled here. Isn't this by design? 

   "It's not auto-loaded so users will have to "(require
    'magit-simple-keys)" in their .emacs explicitly to use it anyway."

Re: [PATCH 4/4] reflog-walk: always make HEAD< at >{0} show indexed selectors

Jeff King — 2012-05-07T21:37:52


Yeah, I noticed that, but decided not to tackle it, as nobody had really
complained (and you can get the behavior you want with master< at >{now}).
However, I agree it would be better for "--date=default" to trigger the
date-based selector.


Maybe. It has been that way for years and nobody has yet complained. :)


I think that is the right way forward.  I am worried that we will end up
with parts of the code that do not handle the distinction properly (see
below). But maybe it is best to try it and shake the bugs out.


It is. The enum at least explicitly starts at 0 for this reason, but I
don't mind at all if it is updated to an explicit '!= DATE_NORMAL'.


I think some of the callers set dmode to DATE_NORMAL explicitly. So this
code would be confused into thinking that the user had asked for it
explicitly. Or maybe it happens before the date_mode_explicit check, and
it would be OK. I'd have to do audit the code.

-Peff

Re: [git] Re: Bug in git-stash(.sh) ?

Eli Barzilay — 2012-05-04T22:36:42

Here's another idea for an easier patch that instead of fixing the
issue with space just spits out a better error: before throwing the
"Too many revisions specified" error, check if "$*" matches "{.*}"
and if "$1" matches "{[^}]*" and in that case make the error say that
spaces are not supported.  The change is therefore only in the error,
and with a fixed output, that should be enough.

(Please tell me if the above or this is desirable...)

Re: [git] Re: Bug in git-stash(.sh) ?

Eli Barzilay — 2012-05-04T18:57:33

Apologies -- it wasn't clear to me what should be done to address the
general problem, and I don't think that I'd do a good job with that
anyway.

I can still make a proper patch with the fix for git-stash.sh that
avoids the problem with the spaces.