editor help to properly format git commit messages

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

--

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Bug in git-stash(.sh) ?

[Note: cross-posted to the magit list to see if anyone else has this
problem.]

For a while now I had a problem when I try to do stash operations via
magit -- for example, it shows this in the process buffer:

  $ git --no-pager stash apply stash@{2012-04-27 08:53:30 -0400}
  Too many revisions specified: stash@{2012-04-27 08:53:30 -0400}

I tracked this down to this part of the script:

	REV=$(git rev-parse --no-flags --symbolic "$@") || exit 1
	...
	set -- $REV

where $REV has one symbolic name but the name has spaces in it.  (This
was introduced two years ago, in ef76312.)

Removing the --symbolic flag could solve this but it looks like it's
needed for error reporting.  Instead, I tweaked IFS so it's split
correctly and added some quotations later in the script where $1 and
$REV are used without quotes.  (I also moved the "REV=..." line next
to the "set -- $REV", since the chunk of code between them isn't using
$REV.)

The following is the diff -- if it looks right I can send a properly
formatted patch.

-------------------------------------------------------------------------------
diff --git a/git-stash.sh b/git-stash.sh

[PATCH] Make autoload creation parallel-make-safe.

Autoload creation must not happen until after magit.elc has been compiled,
otherwise it risks picking up autoloads from the intermediate magit.tmp.el
and creating autoloads that reference a nonexistent file.

Adding a dependency on the .elc fixes this.
---
 Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 1785ca9..2d247de 100644
--- a/Makefile
+++ b/Makefile
@@ -34,7 +34,7 @@ magit.spec: magit.spec.in
 magit-pkg.el: magit-pkg.el.in
 	sed -e s/@VERSION@/$(VERSION)/ < $< > $@

-50magit.el: $(ELS)
+50magit.el: $(ELS) magit.elc
 	$(BATCH) -eval "(progn (defvar generated-autoload-file nil) (let ((generated-autoload-file
\"$(PWD)/50magit.el\") (make-backup-files nil)) (update-directory-autoloads \".\")))"

 magit.elc: magit.el
--

-- 
1.7.10.151.g08b2b

[PATCH] Fix references to the `magit-git-dir' at commit time.

Currently, `magit-log-edit-commit' erases and buries the commit log buffer, then
proceeds to do things that rely on the `magit-git-dir'.  This function isn't
going to work as expected unless the buffer that is current after `bury-buffer'
is located under the `magit-git-dir' -- but there is no guarantee of that.
Indeed there is no guarantee that any such buffers exist (they may all have been
deleted).  Given the semantics of `bury-buffer' it is sheer luck if you end
up in the right place, and it is quite likely that `magit-git-dir' will simply
crash.

The solution is to record the *magit* buffer itself (not its name, the buffer
itself) in a variable local to the commit log buffer, so that it is guaranteed
that we always have a suitable buffer to switch back to even if it's been
killed, then switch back to it at `magit-log-edit-commit' time.
---
Changes since last posting:

 - defvarred the new local variable we use (though it is still made local
   only when necessary)

 - renamed that variable to 'magit-buffer-internal' to emphasise its
   internal nature.  (Possibly 'magit-buffer-tracking-internal' or
   something would be a better name. Also this bikeshed should be
   tartan.)

 magit.el |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/magit.el b/magit.el
index ec43fcc..df6a8df 100644
--- a/magit.el

[PATCH] Fix references to the `magit-git-dir' at commit time.

Currently, `magit-log-edit-commit' erases and buries the commit log buffer, then
proceeds to do things that rely on the `magit-git-dir'. This function isn't
going to work as expected unless the buffer that is current after `bury-buffer'
is located under the `magit-git-dir' -- but there is no guarantee of that.
Indeed there is no guarantee that any such buffers exist (they may all have been
deleted). Given the semantics of `bury-buffer' it is sheer luck if you end
up in the right place, and it is quite likely that `magit-git-dir' will simply
crash.

The solution is to record the *magit* buffer itself (not its name, the buffer
itself) in a variable local to the commit log buffer, so that it is guaranteed
that we always have a suitable buffer to switch back to even if it's been
killed, then switch back to it at `magit-log-edit-commit' time.
---
 magit.el |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/magit.el b/magit.el
index ec43fcc..fb7b142 100644
--- a/magit.el
+++ b/magit.el
@@ -4448,7 +4448,9 @@ environment (potentially empty)."
                                 (if sign-off '("--signoff") '()))))))))
     ;; shouldn't we kill that buffer altogether?
     (erase-buffer)
-    (bury-buffer)
+    (let ((magit-buf magit-buffer))
+      (bury-buffer)
+      (set-buffer magit-buf))
     (when (file-exists-p (concat (magit-git-dir) "MERGE_MSG"))

How to install magit on emacs without root permission

Hi All,

     I downloaded magit-1.1.1  from https://github.com/magit/magit/downloads
and in http://zagadka.vm.bytemark.co.uk/magit/ mentioned  the
following steps to install it

sh ./autogen.sh
./configure [опции]
make && make install

there is no autogen.sh or configure file in magit-1.1.1 and I don't
want to install in /usr/local/share/emacs/site-lisp/ folder . I want
to install it in $HOME/emacs.d/site-lisp folder  .  If I copy all .el
files in to  $HOME/emacs.d/site-lisp folder will it work? .

thanks:
   Anoop

Adding key-mode switches to keys w/o switches?

Maybe this is just a result of me being an Elisp newbie, but I can't figure out
how to add a switch to a key-mode that doesn't have switches by default. For
instances, this works fine:

(eval-after-load 'magit
  '(magit-key-mode-insert-switch 'pushing "-u" "Set upstream" "-u"))

But if I use 'branching instead of 'pushing, I get:

Wrong type argument: consp, nil.

I imagine there's some other function I can call that would do what I want, but
I can't figure it out just from looking at the source.

Setting GIT_AUTHOR_* causes incorrect commit dates

Good afternoon,

I've been having a problem intermittently over the past month or so
that I finally took the time to track down yesterday. The symptom is
that I'd commit something to the git repository at work using magit,
and when I looked at the commit log, the date was in the past. This
was first pointed out to me by a co-worker who asked if I'd managed to
invent a time machine: fixing a bug we discovered yesterday a week ago
is a pretty neat party trick. Once I confirmed that I truly was not
Dr. Sam Beckett [1], I decided to track down the problem.

Yesterday I noticed that a commit made through Magit had the incorrect
date, while a commit made from the command line (outside of Emacs) had
the correct date. When I started looking at magit.el, I found the
setting of GIT_AUTHOR_DATE in magit-log-edit-setup-author-env. My
hypothesis, which I was able to confirm, is that when you rewrite a
commit, GIT_AUTHOR_DATE is set. However, despite the fact
process-environment is set up as a local variable, the setting
persists -- running (get-env "GIT_AUTHOR_DATE") in *scratch* after
rewriting a commit returns the rewritten commit's date. Future commits
will all have the same date as the last rewritten commit.

I started to go down the path of clearing the GIT_AUTHOR_* variables
from the process-environment when no author is present, but that would
preclude setting them outside of Emacs. I wonder if instead magit
should specify --author and/or --date to the command line if the
author information is present.

Does that seem reasonable? Has anyone else run into this issue?

Going from 0.8.1 to 1.1.1: getting the old feel back

Platform: debian testing
          GNU Emacs 23.4.1
          magit 1.1.1-1

I'm trying out the debian package for 1.1.1 after having used the 0.8.1
version in ELPA (http://tromey.com/elpa/ ) for a long time.

Is it possible to:
 1. make magit-status fill the current frame instead of split the frame
    in two? (`M-x magit-status RET C-x 0' is a bit long and complex to
    type every time)
 2. get the single key operation back for `f', `p' and `l'?  I tried
    using the magit-simple-keys as explained in README.debian, but that
    didn't have any effect

Thanks!

- Steinar

(Tracking) Branches in Magit

Hi List, 
I still don't understand the way branches are shown in magit, especially
the relation between tracking branches and its local copies.

Here is the situation:

,------------------------------------------------
| $ git branch  # local branch
| * master
| 
| $ git branch -r  # remote branch
|   origin/master
|
| $ git remote # repository alias
| origin
|
| 
| $ git remote show origin
| * remote origin
|   Fetch URL: git@...:ab.git
|   Push  URL: git@...:ab.git
|   HEAD branch: master
|   Remote branch:
|     master tracked
|   Local ref configured for 'git push':
|     master pushes to master (local out of date)
| 
`------------------------------------------------

spaces in file names cause problems on windows