Ok, I did try that and re-did the pull and it seems to still get stuck on the same issue :9
I've turned on
toggle-debug-on-error and am re-doing it, in the hopes I could find more details
hmm, this time it got stuck at a different number, with no errors produced
four hours later, its still stuck at 871/1936 -- is there some debugging I can do here?
@tarsius: what do you think about setting a new default prefix for annex so as not to conflict with forge?
oops, maybe that's a question for kyle meyer
should I open an issue
This message is replying to a Matrix event but we were unable to find associated bridged Gitter message to put it in the appropriate threaded conversation.
I don't think there's a macro for it, but you could do (lambda (&rest _args) 42)
is there a way to get the status buffer to stop warning me about no newline at the end of symlink files?
or is there a way to configure this for git diff, since I'm guessing that's where magit gets it
I believe it's referring to the symlink itself. I'm committing the symlink
correct. I'm using git-annex, so it's a binary file I don't want in the repo directly
Hm, I don't know how git handles symlinks to external files. I'd assume just as symlinks to files in the repo itself. But a symlink shouldn't have newline problems. Did you check if core.symlinks is true in your repo? If not, symlinks are converted to text files containing the path of the target (a workaround for file systems without real symlinks).
@tsdh:
core.symlinks is true, I can open the symlinked files just fine in the working tree. the mime encoding is binary and the mime type is inode/symlink
I guess this is really a git diff issue, but since you're trying to reproduce, I see it in all cases (the diff engine does the same thing for all of them anyway, so idk how that happened to you)
mkdir -p ~/tmp/git-symlink-no-newline
cd ~/tmp/git-symlink-no-newline
git init
touch test.txt
ln -s test.txt link.txt
git add *
# these both show it
git diff --cached
emacs --eval '(magit-status)'
git commit -m "Test git diff symlink no newline issue"
# so do these
git show HEAD
emacs --eval '(magit-show-commit "HEAD")'
So indeed symlinks are displayed in the git diff as files containing the target file name without newline.
I'm scratching my head and can't figure out this one.
I have a transient with two similar functions:
(defun frame-width-shrink ()
(interactive)
(set-frame-width nil (- (frame-width) 5)))
(defun frame-width-widen ()
(interactive)
(set-frame-width nil (+ (frame-width) 5)))
(transient-define-prefix frame-size-transient ()
[("H" "shrink frame width" frame-width-shrink :transient t)
("L" "widen frame width" frame-width-widen :transient t)])It looks totally fine, right? But my conundrum is that for some reason, widening works while shrinking doesn't. Calling the command manually - works. Evaling it - also works. If I make it ("H" "shrink frame width" frame-width-shrink :transient nil) - it works. But I need it to be transient.
Can someone think of a reason why wouldn't it work? Specifically, it doesn't work when invoked from the transient popup. Everywhere else - it works.
And do you mean that it happens in a terminal, but not in a GUI Emacs?
I've got one emacs server running and use it from the command line and the GUI
I just have my
EDITOR set to stay in the terminal.
shepmaster (Jake Goulding): Seems like more of an Emacs issue than a Magit issue, since it would affect anything that did what Magit does AFAIK.
I’m working on a project that happens to be developed on Windows 10, and it’s reminding me how slow magit can feel on Windows… what’s the current thinking on optimizing magit for Windows?
1 reply
is there a way to get the "files changed" from a pull request in github into magit? the workaround I found to get what I wanted was to use get to the log screen (l l), select the commits I want and get the diff (d). I'm reading through Forge manual to see if it has that option, but if someone knows how I could get that info, ideas are welcome. thanks!
Hi all, I'm trying to learn more magit to switch over from my CLI workflow. I often do
git rebase -i (git merge-base origin/master HEAD) in order to edit commits since branch-off from master but without rebasing over new commits on master. Wondering if there's something similar in magit?
@dongcarl: magit already has a way to work out the commit you're looking for when you call
b s, I think. so it might be an easy change
If you’ve already selected a commit in “recent commits”, or in the magit log (
l l or l b), then rebase interactive (r i) uses that commit. Granted, it doesn’t figure out the common base automatically.
hi, how can I set the magit status buffer to revert automatically when I commit something? currently when I commit something, I have to press
g to get the magit status buffer updated. the magit-auto-revert mode is enabled in my config. any ideas here? thanks!
it seems that should be the default with
magit-refresh-status-buffer but it doesn't seem to be working for me
it seems that it doesn't happen with all repos, so maybe a pre commit hook is causing this