I found interesting problem with magit - I use it to switch between branches, and sometimes, it modifies opened buffers during switching. It not always reproducible, but I see this pretty often.
Steps to reproduce:

• Open number of files from repository with code
• switch to another branch, where these files had another content
• check status of opened files

I've got a UTF-8 -encoded python file which contains a "LATIN SMALL LETTER C WITH CEDILLA" (U+00E7) in a comment. The file starts with emacs' usual "# -*- coding: utf-8 -*-" indicator, and emacs correctly handles the character. When I make changes to the file and then attempt to stage them (with "s" in the magit-status buffer), if I try to stage the hunk that contains the U+00E7, I get a "git failed" message that says "git --no-pager apply --cached -: patch failed: patch does not apply". Staging other hunks works fine, as does staging the entire file.

I suspect that the patch which magit.el is computing (and piping in to git-apply) is using the wrong character-encoding, so the context lines (including the U+00E7) come out as something else, which then does not match the existing file.

I don't know how emacs handles character encoding.. maybe magit needs to examine the encoding settings of the file being staged and use it in the process buffer through which it invokes git-apply ?

thanks!
-Brian

When you view hunks in magit you can press RET on everything from @@ to the last line here, except the one starting with - to view the change in the file:

Changes:
    Modified po-mode.el
diff --git a/po-mode.el b/po-mode.el
index 7b843c7..3a59da2 100644
--- a/po-mode.el
+++ b/po-mode.el
@@ -1173,3 +1173,3 @@ all reachable through 'M-x customize', in group 'Emacs.Editing.I18n.Po'."

-  (po-check-file-header)                                                                                                                                   +  ;(po-check-file-header)
   (po-compute-counters nil)

However, this does not work if you (setq magit-diff-context-lines 0):

--- a/po-mode.el
+++ b/po-mode.el
@@ -1174 +1174 @@ all reachable through 'M-x customize', in group 'Emacs.Editing.I18n.Po'."
-  (po-check-file-header)
+  ;(po-check-file-header)

In that case RET on the @@ or + lines will give you "Hunk header not found", and - will continue not to work (see another related bug I'm filing for that).

This is in the key-groups branch.

When trying to do 'a' to cherry-pick a commit from magit-log (generated by "l -a l", i.e. a short log with the --all option set), I got the message in the title of this bug. In Messages, I got:

proof-setup-func-menu: Symbol's function definition is void: magit-log-edit-set-field

I just hit 'x' instead of 'z' and then just hit enter when questioned about it.

Perhaps we could optionally have 'x' place changes into a "stashcan" which a user can then just kill if they want to. Interfering with git too much?

I would find it very useful to be able to pull from multiple remote repositories in the same way you can push to them (C-u P). For example using a key mapping like C-u F?

`l' gave me this line for one commit:

7a4d10dd * cosmetic Use Path for cleanliness

the actual commit comment is “(cosmetic) Use Path for cleanliness”

On a brand new repo, staged files must be unstaged with git rm --cache (as advised in the git-status output).
Could it be that magit-unstage-item always does a git-reset even before the initial commit ?

When working with a file in a remote repository through tramp, e.g.:

/ssh:there:/home/dov/foo/bar.txt

magit does not recognize this syntax and thus does not initiate interaction with the remote repository 'foo' on host 'there.

Magit doesn't seem to support git-blame at all. This is one of the git features that I think really benefits from Emacs integration; it's cumbersome to use git-blame on the command line.

When any of git subprojects' (submodules) directory is dirty (i.e. anything is modified there) Magit disallows doing rewrites. IMO it should not disallow it, since it is not risky

title says all

Here's what Git itself says:

$ git show --pretty=oneline | head -n1
86028be4 add an extra \n to all tests when --verbose and running under a harness

And here's the magit rebase-mode buffer:

pick 86028be add an extra n to all tests when --verbose and running under a harness

The magit log buffer retains the \n, there's some problem with rebase-mode that removes the \ in \n, and presumably this is the case for other escapes as well.

git rebase -i now supports exec / x in git's next branch

exec takes a free-form shell command to run after pick/squash/fixup etc. So rebase-mode will have to change to support that. That'd mean changing toggle-read-only-mode or something like that.

I just did a b <branchname>' in a magit-log buffer and everything seemed fine. I had to $' to find out that I had a problem:

$ /opt/local/bin/git --no-pager checkout install-from-git
error: Untracked working tree file 'runt' would be overwritten by merge.

This is probably true of all buffers; I'd like to see the current branch somewhere just as in the magit-status buffer.

title says all

If my ssh key is protected with a password, then magit fails to push. The magit-process displays the following and is stuck:

$ git --no-pager push -v origin master
Pushing to ssh://spot/home/dov/dov-bsolar.git
Enter passphrase for key '/home/dov/.ssh/id_dsa':

But since the magit-process buffer is read only there is no way to input the password and thus no way to push the repository.

System is:
Fedora release 13 (Goddard)
Kernel: 2.6.33.6-147.fc13.i686
Emacs: GNU Emacs 23.0.94.1 (i686-pc-linux-gnu, GTK+ Version 2.16.1)
Magit version: Not sure as the magit.el doesn't contain the magit version...

subject says all

I only have myself to blame for this, but I did the equivalent of:

git mv old-name.sh new-name.sh

Then I opened magit and typed a long commit message. While doing this I was experimenting with the source tree, and cleared out the index, so there was nothing to commit. When I commited in magit I got this:

$ git --no-pager commit -F - --signoff
(reading log message from standard input)
nothing added to commit but untracked files present (use "git add" to track)
Git exited abnormally with code 1.

Which is to be expected. But, it would be very helpful if the commit message for a failed commit went into the kill ring, so you didn't have to type it all out again.

Magit should know about the bisect refs so that we can see good/bad commits.

I'm not sure why this is occuring but a local tracking branch isn't pushing to the correct location, but instead creates a new branch with the local tracking branch name. I found that explicitly naming the ref branch will do the right thing. So here's a patch that solved my issue.

http://gist.github.com/440701

I have http://github.com/dabrahams/pip/tree/pip-misc checked out. This is what I'm seeing in my magit-status buffer:

Remote: pip-misc ../pip-misc.git
Local:  pip-misc ~/src/ryppl-work/pip/git/ryp/
Head:   7296e51 This file gets written by the install test, causing the source tree to appear outdated to source control when it shows up with Windows line-endings.  Really this whole package should be copied elsewhere before it is installed (see http://bitbucket.org/ianb/pip/issue/108)

Untracked files:
        tests/.noseids

Stashes:
0: On file-scheme: Snapshot taken at 2010-05-19 16:52:47
1: On file-scheme: Snapshot taken at 2010-05-19 16:37:45

Unpulled commits:
fatal: ambiguous argument 'HEAD..pip-misc/pip-misc': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

Unpushed commits:
fatal: ambiguous argument 'pip-misc/pip-misc..HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

Init a repo, stage a file, then press "u" on it. Git will fail.

When a file with DOS line endings is changed, operations on hunks no longer work.

Steps to reproduce:
create a git repo
add a file with dos line endings (I did this by creating a file and then using unix2dos to change the line endings)
commit the file
edit the file
try to remove edited hunk (not all edits on the file!)

I usually run emacs-24 (trunk), and a few days ago magit (master) started to have problems executing the git process. I reverted to emacs-23.2 branch, and it works fine with the same magit master.

The simplest example is that I could stage hunks in the index, then enter the commit window, and compose your commit message. When I commit, it says git is already running, and I can see in the git process window that the git add command never returned, although it did complete its work. I can commit from the command line to complete the operation. However, I must kill the magit-process buffer before I can start another operation. This appears to be generally the same for any git operation with Emacs-24 now.

In fact, most keybindings (`C-h b') don't seem to work in the long log buffer

In this gist I have an Emacs keyboard macro. This macro contains ^S and other control characters.

Trying to stage a hunk with control characters like these doesn't work. magit either hangs, or finishes with a partially staged chunk.

git clone git://gist.github.com/560707.git gist-560707
cd gist-560707/
git reset --soft HEAD^
git reset test.txt

Somewhere along the line the control characters aren't being correctly printed out when they're passed to the git process.

Here's the usecase. Say I have a stash that I haven't touched in a while, so I do "a" on it, find that it gives me a bunch of unmerged stuff and is old and out of date anyway. Now I want to nuke the changes it made.

I can "k" on the staged/changed files it'll add. But these:

Unstaged changes:
    Unmerged builtin/fetch.c                                                                                                                                 
    Unmerged builtin/merge.c

Will cause a "Git failed":

$ git --no-pager checkout -- builtin/fetch.c
error: path 'builtin/fetch.c' is unmerged

Maybe it should do this on unmerged files (after asking "are you really sure"):

git checkout --ours builtin/fetch.c && git add builtin/fetch.c

Or:

git checkout HEAD -- builtin/fetch.c

I would like an option to view changes within files using ediff as well.

Wazzup doesn't bind the "i" key to magit-ignore-item as advertised in the manual; http://philjackson.github.com/magit/magit.html#Wazzup

I'll send a pull request for:

http://github.com/remvee/magit/commit/156ff61f912892c3da9c560af3c8d1c47fa00063

My recent patch has caused some problems, I have made it a bit more flexible, and now will only push explicitly when a ref branch is present, other than that i'll try and push to the branch.

Here's the patch. Thanks to binjo to pointing out that I should just push to branch not an empty string.
http://gist.github.com/448664

When you have hunks like the ones described in Issue 53 RET on a line that's been removed will return "Can't visit removed lines".

That's needlessly uncooperative. magit should just visit the nearest adjacent added line in that case, or something like that. When you RET on a hunk like that you want to see the context in the file, you don't want to move the cursor down a few lines to do so.

It seems magit-interactive-resolve-item removes a newline from the bottom of the resulting buffer

I used to be able to do `C-u l RET --glob=* RET RET' and see a log of everything. Now I get

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("^\\(.*\\<HEAD\\)\\([~^].*\\|$\\)" nil)
  magit-name-rev("--glob=*")
  magit-rev-describe("--glob=*")
  magit-rev-range-describe(("--glob=*") "Commits")
  magit-refresh-log-buffer(("--glob=*") "--pretty=oneline" ("--glob=*"))
  apply(magit-refresh-log-buffer (("--glob=*") "--pretty=oneline" ("--glob=*")))
  magit-refresh-buffer()
  magit-mode-init("/Users/dave/src/wiegleymacs/" log magit-refresh-log-buffer ("--glob=*") "--pretty=oneline" ("--glob=*"))
  magit-display-log((4))
  magit-log((4))
  call-interactively(magit-log nil nil)

hi,

is it possible to have a callback as an argument of magit-run-git-async while calling magit-run-git-async and let it process the return status, something like `url-retrieve'?

Thanks,

subject says all

Title says all

When there is two repository whose directory name is the same, magit use the same buffer for both, making even more difficult to know in which one I'm

hi,

I'm using git version 1.7.0.2.msysgit.0 in windows xp sp3. When pushing repos via magit, the process filter is bounded to process "git.exe", whereas the passphase to input is prompted by "ssh.exe", which is created by "git.exe". So basically the `magit-password' is nerver called correctly. Is this possible to resolve?

Thanks.

(magit-guess-branch) will offer a choice between e.g. next (upstream) and next (origin). This means that I can type this in a shell:

git rebase -i upstream/next

But in magit's E I have to complete to:

next (upstream)

Maybe it'd be worth it to also supply the remote/(.*) completions as-is, but then again they might clutter stuff up.

Personally I just disable magit-log-fill-paragraph (see my patch), but it fails on cases like:

* taohe usntoahuentoaheu sntheoa sntuhoae huasnteo husnteoa husntoaeh usntoahe usntoa huentoaheu snthaoesunthoasue 

If I M-q that it doesn't work like in text-mode.

Sometimes I'd like to always pull a branch from remote #1 and always push it to remote #2. It'd be nice if we could set the default push url for a branch. I know, this should probably be a Git feature, but until then it'd be awesome to have it in Magit.

git log show correctly encoded subject only for predefined pretty format - oneline, full etc.

When pretty uses custom string such as "%s" it should also use "%e" (commit encoding), then do recoding from commit encoding to repo's logOutputEncoding (perhaps to utf8 first).

Or magit can use something like
git log --pretty=oneline | cut -d ' ' -f 2
leaving internal encodings to git.

How to reprocude:

$ locale
LANG=ru_RU.CP1251
LC_CTYPE="ru_RU.CP1251"
LC_NUMERIC="ru_RU.CP1251"
LC_TIME="ru_RU.CP1251"
LC_COLLATE="ru_RU.CP1251"
LC_MONETARY="ru_RU.CP1251"
LC_MESSAGES="ru_RU.CP1251"
LC_PAPER="ru_RU.CP1251"
LC_NAME="ru_RU.CP1251"
LC_ADDRESS="ru_RU.CP1251"
LC_TELEPHONE="ru_RU.CP1251"
LC_MEASUREMENT="ru_RU.CP1251"
LC_IDENTIFICATION="ru_RU.CP1251"
LC_ALL=

$ mkdir git-subject-bug

$ cd git-subject-bug

$ git init

Initialized empty Git repository in .../git-subject-bug/.git/

$ touch test

$ git add .

$ git config i18n.commitEncoding cp1251

$ git config i18n.logOutputEncoding cp1251

Do commit with non latin message

$ git commit -a -m "Тест"

$ export LANG=ru_RU.UTF-8

$ git config i18n.logOutputEncoding utf8

$ git config i18n.commitEncoding utf8

Run xterm with new locale settings

$ xterm

Readable output

$ git log --pretty=oneline

Broken encoding

$ git log --pretty="%H %s"

subject says all

In the magit-status buffer, I see something like this:

Untracked files:
predictive-dicts/dict-alexey-a.el
predictive-dicts/dict-alexey.el

Stashes:
0: WIP on master: bd2fc04 update package.el to 0.9.4
1: WIP on master: 2d1abd5 had to readd .gitignore and .gitmodules

Unpulled commits:
'c:\Program' is not recognized as an internal or external command,
operable program or batch file.

Unpulled commits (SVN):
'c:\Program' is not recognized as an internal or external command,
operable program or batch file.

Apparently magit is trying to access some path in C:/Program Files/, but which one and where does it get the path from? There are no such paths in the magit customization group.

"Magit Git Executable" is simply git, since it's on the path.

I very commonly need to get from a magit-log buffer to the corresponding magit: buffer. There should be a keybinding for that. Similarly from the magit-diff buffers, etc.

This is very limiting because you can't e.g. have a rebase buffer open while making commits to some other unrelated project.

Sadly, I have to use MacOS at work. Despite being hyped as a developer OS, it ships with an outdated emacs. So I used GNU Emacs.app instead. The binary is not in the /usr/bin, but instead in weird place /Applications/Emacs.app/Contents/MacOS/Emacs. I haven't found the magic ./configure incantation to use this binary to byte-compile magit using make. It would be nice if there were more ./configure options that allowed the user to specify the exactly emacs binary to use in byte compilation, and the exactly load path of the lisp files belonging to this emacs binary.

Thanks,
Chad

Occasionally I'll see something like this in my log buffer:

19e5eb09 | | * Got things running on Windows again, finally!
0635c57b | | * Allow git to pull from local repositories
17d83d1a | | * cosmetic Use Path for cleanliness
4ea79503 | | * Implemented ability to request a revision by name from the repository.
         | |/  
         |/|   
1c6b2517 * | pip-win32/master win32 Neutered broken test_freeze_with_local_option test (see http://bitbucket.org/ianb/pip/issue/110)
e13f9ab0 * | Repair the test_uninstall_rollback test
124fdc38 * | Missed Win32 portability opportunity
50080e62 * | Snarky note about sloppy check

which makes it look like revision histories are colliding. I suggest this formatting instead:

19e5eb09 | | * Got things running on Windows again, finally!
0635c57b | | * Allow git to pull from local repositories
17d83d1a | | * cosmetic Use Path for cleanliness
4ea79503 | | * Implemented ability to request a revision by name from the repository.
         | | |  
         |/ /   
1c6b2517 * | pip-win32/master win32 Neutered broken test_freeze_with_local_option test (see http://bitbucket.org/ianb/pip/issue/110)
e13f9ab0 * | Repair the test_uninstall_rollback test
124fdc38 * | Missed Win32 portability opportunity
50080e62 * | Snarky note about sloppy check