I haven't tried it yet but vcsh sounds interesting.
--
---
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.com.
For more options, visit ht
On Tuesday, August 27, 2013 3:40:07 PM UTC+2, Philip Jackson wrote:
>
> People were generally happy with the popup menus elsewhere
> but I pulled it out of commit because there was so much
> resistance.
>
I didn't know that.
My two cents; I'm not sure I like the new way. I find the menu is
On Thursday, August 29, 2013 4:13:31 PM UTC+2, Tom Davis wrote:a
> Overall I'd call it a great addition despite the annoyance of having to
> hit "c c" because, for the times when I *did* need options, I simply
> couldn't use magit at all for that commit.
Thanks, I am glad this helps at least o
ected I am currently investigating whether it is still possible to
revert the removal of magit-log-edit and giving users the choice between
the two modes.
Sorry,
Jonas Bernoulli
--
---
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubsc
Magit not supporting these environment variables is a bug. I don't think
you should add hooks or use advice. We have to fix this, it's a serious
issue.
It would be great if you could start working on this in a feature branch. I
don't know how much work it will be to fix this. It might be a lot
> Is this part of the reason for the new commit method? So that things that
> work on the
> command line via normal git tools will also work from inside magit?
>
Yes.
--
---
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from thi
Hi List :-)
TL;DR We should move to another mailing list implementation and host. The
current list will remain as a read-only archive. I propose to move to
Savannah. I expect this move to be painless.
---
I have already talked to the people at Savannah. They are willing to create
a list for
Indeed my message above came as both test and html. Lets see what
responding from Gmail and *adding some formatting does.*
Anyway, another reason I want to make this move is that I don't want to
rely on Google.
--
---
You received this message because you are subscribed to the Google Groups
"
> IIRC there was an "old-magit compatibility special mode" for those who
> disliked key-groups. Maybe it was removed, dunno.
>
The file `magit-keys.el' was removed but it was replaced with a variable:
`magit-rigit-key-bindings' which is "not an option to avoid advertising
it". I don't recomme
npost...@gmail.com writes:
> On Tue, Sep 3, 2013 at 4:50 AM, Neale Swinnerton wrote:
>>
>> I'm struggling to see how to set some default options. I'd like to make
>> '-S' (--gpg-sign) default on when commiting and '-s' (--sign) default on
>> when tagging.
>>
>> Is this supported?
>> Is this a bad
Hi List
There are a few discussion type issues open on Github that you might
want to comment on. It would probably be better to comment on Github
(since that is where this discussions began) but you may also do so
here (but then change the subject accordingly.)
* Should we drop support for Git v
I have just made the old commit mode available as a separate package. Until the
new commit mode is functioning in all its glory, you might or might not want to
use that.
The repository is a https://github.com/magit/magit-log-edit it should also
appear on Melpa any time now.
If you find a probl
naes...@gmail.com writes:
> Does this still/again allow adjusting what is to be committed as you
> edit the commit message? That capability is important to many of us
I would think so, give it a try.
> (Also, I find this new habit of sticking vital portions of magit in
> separate repositories d
That is possible:
emacsclient -e '(magit-diff "rev1:file1" nil (list "rev2:file2"))'
But there are some limitations:
- The heading won't make much sense. In the above example it would be "Changes
in rev1:file1".
- The second argument to magit-diff should always be nil.
- You cannot specify
> While editing a file in a buffer, I sometimes want to see the unstaged
> changes for just that file; I am used to using vc-diff or
> ediff-revision for this. I can't figure out a straightforward way to
> do this using magit.
I am afraid that doesn't exist yet. But it should. I am juggling qui
There is an issue for this in the bug tracker. Could you please comment there.
Thanks.
https://github.com/magit/magit/issues/1142
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send a
Ups, wrong issue. This is the right one:
https://github.com/magit/magit/issues/1128
Ps: Feel free to comment here instead. I though that issue was still open and
that I could not reproduce it and needed help to investigate it. That isn't the
case.
--
You received this message because you are
> I didn't know about this "git rebase --interactive" getting as usable
> as magit rewriting.
See https://github.com/magit/magit/issues/877 for a comparison of rebase,
cherry-pick and magit's rewrite.
--
You received this message because you are subscribed to the Google Groups
"magit" group.
On Friday, January 17, 2014 4:37:42 PM UTC+1, Jonas Bernoulli wrote:
> > I didn't know about this "git rebase --interactive" getting as usable
> > as magit rewriting.
>
> See https://github.com/magit/magit/issues/877 for a comparison of rebase,
> cherry-p
> The "old school-style" suggests to me that there's a newer, better way
> to start an interactive rebase. Is there? If so, how?
The doc-string is misleading (and will be fixed). This is the recommended way
of doing this sort of thing.
--
You received this message because you are subscribed t
> Is there any way to set this behaviour as the default?
Not yet, but I am currently working on such features.
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+un
Magit should only turn on auto-revert-mode for files tracked by Git. It did
always automatically revert these files, but used its own code to do so.
Anyway, I agree this needs some fine tuning and could be improved. Doing so
might take some time though.
Jonas
--
You received this message beca
>> Magit should only turn on auto-revert-mode for files tracked by
>> Git. It did always automatically revert these files, but used its
>> own code to do so.
>>
>> Anyway, I agree this needs some fine tuning and could be
>> improved. Doing so might take some time though.
> The main problem is that
Noam Postavsky writes:
> On Wed, Mar 5, 2014 at 1:10 PM, Jonas Bernoulli wrote:
>> I do agree that having some functionality turned on by just loading
>> a library isn't good. But it is also how Magit has always done it,
>> I just made it do so by using a built-in
ups, send before being done
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups
...continued...
So the only difference is that this risk exists now not only when running git
using magit, but also when running it on the command line. For this part of the
issue I am taking responsibly and because I don't want to be responsible for
data loss, magit now no longer turns on `aut
Please have a look at https://github.com/magit/magit/pull/1268 and test it. I
think that should do it for the time being.
With this *tracked* files are automatically reverted but only in the *current*
repository and only after a *Magit command* did run. As such it mostly restores
the behavior f
Fixed with ef0311dc47bcd5af2fbff10ff6953ca1aee5d81f.
Thanks for reporting.
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.com.
For more
You can undo the changes introduced by a particular commit by pressing
RET on that commit moving to the file and then pressing v.
Magit does not support reverting everything that has happended to a file
after a certain commit (i.e. it might have changed in several commits).
To do that use:
$
I have implemented that on the 'next' branch but it will be a while
until that is merged into 'master'.
> Is there a single command to do a "git stash branch" in magit?
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and
It's called `magit-show`.
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout
Could you please `M-x toggle-debug-on-error` and then repeat your steps.
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.com.
For more op
It's a bug. I have pushed a fix.
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/
Should be fixed now.
See f2d35643b39f8293d5ef4683c2792a8b1a2ed326.
Thanks for reporting
Jonas
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@goo
In the magit screenshot I noticed that nothing is displayed after
"Head:". That indicates that Git is unable to determine the current
branch.
Please check whether you have somehow set the location of the gitdir and
the work tree. There are several ways of doing that, including the
variables GIT_
> Hi Janos,
Oah! Another potential name for the OS I surely will create eventually: JanOS
:-)
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@google
> I would prefer, that the `--all' switch were active by default,
On the next branch it is possible to specify such default arguments.
See https://github.com/magit/magit/pull/1223
and https://github.com/magit/magit/issues/1220.
--
You received this message because you are subscribed to the Goog
> Sometimes when I click E for ediff, the corresponding file is
> disappeared and shows "no diff at this location" in mode-line.
> And the point goes to the end.
Are you saying that the text representing the file you act on disappears
from the status buffer? That shouldn't happen as far as I know
> Moving the definition of magit-blame-popup earlier in the code, before
> it gets referenced by magit-blame-mode-map, fixed the issue.
A keymap is just data. Whether bindings are valid at the time they are
defined is irrelevant. All that matters is whether they are defined at
the time the keyma
Daniel Hawthorne writes:
> Git version: 2.1.0
>
> git rev-parse --show-toplevel works from shell, but
> (magit-git-string "rev-parse" "--show-toplevel") returns nil.
And what does (magit-git-string "--version") return?
--
You received this message because you are subscribed to the Google Gro
>> just like 's' and 'u'
> press 'k' ?
The commands these keys are bound to are known as "apply variants".
They are implemented using Git commands, mostly `git apply' but as
porcelain commands at least some of them are actually unique to Magit.
I have described them in some more detail in a thread
> When will we see an updated stable release on, for example, Marmalade?
There is a stable "non-release" available from Melpa-Stable. The FAQ
covers why that isn't available from Marmalade also. It also mentions
that we are now in feature freeze, so that we can actually concentrate
on getting a
> At least now I know why it works the way it does and that, sadly, I
> have to live with it.
Or you could read the FAQ and see whether you can do something about it.
https://github.com/magit/magit/wiki/FAQ#what-can-i-do-about-poor-performance
--
You received this message because you are subscr
Alan Schmitt writes:
> Is there a way to configure magit such that frames to write the commit
> message are deleted when the commit is done?
No, there is no builtin support for something like this. You could
probably implement this using some Magit hooks and Emacs options
concerned with this s
> I am trying to build a login system with marmalade web. How do I
> store the user's login information with the Marmalade web SDK?
I think you sent this to the wrong list.
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group
> I would appreciate any guesses as to what could be wrong.
Are symlinks involved?
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.com.
This should be fixed now. I think this was a recent regression which
only kicked in when resolving conflicts. If you still see this in other
situations, let me know.
Jonas
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this gr
Amelie Weisttragger writes:
> When viewing the log (M-x magit-status C-j l l) how can I change the
> "time since commit" to fractional days, rather than ("1 hour" "1 week"
> etc)?
>
> Something like ("1h" "23h" "1.1d" "8d" "365d" "546d") would be good.
You can do that by customizing `magit-log-
> But in reality, in mature projects contiguous changes are often only 1-2
> lines long, making the interspersed annotation a major distraction (that
> is, the source is almost unreadable).
On magit's next branch you can press `t' to only separate chunks
with thin lines instead of headings. (Then
> *ERROR*: Wrong type argument: listp, <<<
This is a conflict marker. Someone accidentally failed to resolve
a conflict and committed the merge with such markers still present.
This doesn't have to be in code related to Magit, it might be in
any code that, for whatever reason, gets loaded wh
> I'd like to know if the same apply to diff.textconv or there is
> something I've to fix in my textconv script.
Probably. But it is hard to know without also knowing what the unknown
driver actually does. If it generates something that doesn't exactly
match the format used by Git, then Magit has
Magit's next branch requires at least Emacs 24.4.
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.com.
For more options, visit https://gr
Providing "/" as a *complication candidate* is the
best Magit can currently do, mostly because there might be more than one
remote and Magit doesn't know whether you prefer "origin/"
or "yourfork/". Instead you might want to give Ido a try,
to make the completion less painful (here and everywhere
Magit v2.1.0 was released on the 1th July.
The release notes can be found here:
https://raw.githubusercontent.com/magit/magit/master/Documentation/RelNotes/2.1.0.txt
You should also read the update instructions:
http://magit.vc/manual/magit/Installation.html
especially this part:
http://ma
> I'm fairly new to both Git and Magit.
While it would probably be possible to do all that is required using
Magit, I strongly recommend you stick to the command line to fix this
issue. An emergency isn't the best time to learn about two new tools.
This is also not the best place to ask such a q
No, that is not supported.
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optou
> What is the meaning of the number in parenthesis, in the "Tag:" line at
> the top of the status buffer?
>
> Head: 9adeb58 python Finish ignoring paths and compiled files.
> Upstream: 9adeb58 origin/python Finish ignoring paths and compiled files.
> Tag: v0.1.0 (7)
These are the commits
Robin Green writes:
> I have installed overcommit[1] as a pre-commit hook. It outputs ANSI
> escape sequences to set colors, and these are rendered as follows in
> the magit-process buffer:
>
> I am not sure who is at fault here. overcommit appears to be doing the
> right thing by testing whethe
Patrick Brinich-Langlois writes:
> When I run magit-blame on a buffer, it prompts me to save other
> buffers (apparently, any unsaved buffer in the same Git repository). I
> can see why it would be necessary to save the buffer I'm blaming, but
> why is it necessary to save the others? I find thi
> (It shouldn't be necessary to save the buffer too -- see
> `git-blame-mode' (from the git contrib directory) that works fine with
> unsaved modifications.)
The buffer has to be saved, or this might happen:
On disk:
added in first commit
added in second commit
In buffer:
new line
new
Jonas Bernoulli writes:
>
> Which means that setting `magit-save-repository-buffers' to `nil',
> *does* break `magit-blame'. I'll fix that soon. Patrick: I'll let you
> know when I am done.
I have changed the behavior as follows: `magit-blame' now alw
Sorry for having lit this thread.
Anyway, I am not going the change the defaults for saving and reverting
file-visiting buffers. It might be unemacsy, but I think the current
behavior does make sense from a Git perspective. It's also what Magit
has been doing for a long time, so changing the beh
/Documentation/RelNotes/2.3.0.txt
-- Jonas Bernoulli
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.com.
For more options, v
Sometimes Git gets confused when you abort a "sequence action" like a
cherry-pick in non-standard way. That causes a file to remain in .git
whose content then ends up being used when creating a new commit. When
that happens, then the buffer used to edit the message should contain a
message like "
Git is informed about you being done editing by `emacsclient' exiting.
When the exit code is zero, then that means that the commit should be
created. Git then takes the message from the file (which was previously
saved by Magit/Emacs), creates the commit using that message, and then
deletes the fi
The `shell' in `INSTALL_INFO ?= $(shell ...)' isn't a command, it's a
make function.
The problem is that `hash's exit status isn't defined in the standard,
so AIX is free to not do the reasonable thing, which it apparently makes
use of...
Now using `command -v' instead.
-- Jonas
--
You receive
What I would do in this situation is to move to the last commit I want
to keep (likely in an "Unpushed to ..." section) and then press "C-u x"
to do a `git reset --hard COMMIT_AT_POINT'.
I think `git-rebase.el' lacks support for the "drop" command because
`git rebase' itself did not support that a
The note from `core.notesRef' is automatically displayed when showing
a revision with such a note. The notes in `notes.displayRef' do not
appear to be automatically displayed, I'll investigate that.
Also see the "Notes" node in the manual.
--
You received this message because you are subscribed
Fixed in
https://github.com/magit/magit/commit/f17fb6a9962002cc2e09be01d2618d502b018965
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to magit+unsubscr...@googlegroups.c
> Any chance mo-git-blame could actually replace the current blame mode to
> encourage contributions?
No chance. But we can take inspirations from it (and tig, git-blame.el,
vc-annotate.el, and others) to implement *alternative* visulization
methods.
I don't think any of the various approaches a
Also there is an alternative (and I believe more popular) solarized
implementation: https://github.com/bbatsov/solarized-emacs. I use
the light variant of that (and have contributed to it). Except for
the lack of colors in popups I like it. In my fork you can find a
commit which makes the popups
> I did a "git stash -u" ... Emacs goes CPU-bound
> Anyone know what might be going on?
You created an exceptionally large commit and it now takes exceptionally
long to display the diff for that. Did you really mean to create a
stash which includes all files in the repository, including those fil
les;
> and that "-a" ("--all") stashes ignored files as well as untracked files.
> So I wouldn't have thought I created an exceptionally large commit. Am I
> confused?
>
> On Wed, Sep 7, 2016 at 4:09 PM Jonas Bernoulli wrote:
>
>> > I did a &qu
> It would be nice to hear the voice of magit users, how you use Git,
> and what you would like to see improved in Git. Magit developers
> are also very welcome.
Thanks for getting in contact! Since this mailing list isn't very
active, so I am going to forwarded this in a few places that get mor
I should probably have announced the Magit fundraising campaign
here a little earlier than this, but in case you have not heard
about it through other channels by now, here goes:
I am running a Kickstarter campaign to fund my work on Magit
for a year. And it ends in only 4 HOURS.
Cheers,
Jon
> I am running a Kickstarter campaign to fund my work on Magit
> for a year. And it ends in only 4 HOURS.
A link would probably help:
https://www.kickstarter.com/projects/1681258897/its-magit-the-magical-git-client?ref=7stnf9
oO
--
You received this message because you are subscribed to th
Aleksander Morgado writes:
> Hey!
Huhu
> I've installed magit via MELPA
You are using the "Melpa-Stable" archive but the Melpa maintainers
recommend that you use the "Melpa" (bleeding-edge) instead because many
packages are not released nearly often enough. (Case in point: Magit.)
No Melpa ma
Samuel Wales writes:
> i am currently using a version of emacs that is probably not supported
> by modern magit. i tried it, anyway.
You'll need at least Emacs 25.1.
> in any case, however, i have been using a paleolithic version of
> magit, because it shows --- +++ headers in the status buffe
78 matches
Mail list logo
