multiple regressions with commit workflow?

[Adam Spiers]

Hi all,

Firstly many thanks for all your awesome work on magit!  It is a massive help to me on a daily basis.

I just updated to the latest git version, and I see a big change in the workflow involved in making a commit.  Previously, four keystrokes (including Shift) would deal with the use case I need 90% of the time: `c' to drop me straight into the commit log buffer, and `C-c C-c' when I'd finished writing the commit log.

However, with the new workflow, there is an extra commit options menu I have to go through the majority of the time even though I don't need any of the options.  Then it appears to invoke emacsclient in order to open a commit log buffer, which means I now have to indicate that I've finished editing via `C-x #' which is more awkward to type.  This has other disadvantages too:

• A git process is started immediately, and then blocks until the emacsclient process completes.  This means that no other git operations are possible until you abort or complete the commit!
• The only way of aborting a commit is to empty the buffer and then type `C-x #', which is more effort than a simple `C-x 0' or similar.
• If I abort in this manner, I get an ugly "git exited abnormally with code 1" error message.
• If nothing is staged, you have to type `-A' instead of simply answering `y' to the prompt which used to exist.
• If I close the commit log buffer's window, I can no longer restore it by typing `c' again from the main Magit buffer. 
• Invoking emacsclient from within emacs, just in order to open a new buffer?!?!!  Surely that is just inviting breakage.

I'm sorry to bring a negative opinion into the group on my first post, but this seems like a large step backwards in the interface, and I'm really puzzled why it was made.  I searched in several places for some announcement or NEWS file which would explain the change, but couldn't find anything.  It seems that there used to be a NEWS file a long time ago, but it was removed in 2010 with a commit message "Removed unneeded files".

I did finally locate https://github.com/magit/magit/issues/675 (by searching the source for one of the strings which appears in the new interface, and running git annotate on that).  AFAICS it appears to be closely related to the above, but it's long and complex and would take me a long time to unravel.  So I wanted to ask:

1. Am I missing something or does this new design genuinely suffer from the above issues?
2. Maybe there are signficant advantages to the new way which I didn't notice yet?
3. Is there a way to solve the issues I list?
4. Or am I the only one who is bothered by them?
   
5. Is it possible to make `C-c C-c' bound to `server-edit' in the emacsclient buffer by default, to minimise the amount of muscle memory that long-time magit users have to re-program? 

Many thanks!

Adam

P.S. Sorry for the rich text message.  I couldn't figure out how to persuade Google Groups to let me compose in plain text, which really sucks :-(

[Adam Spiers]

On Thursday, 22 August 2013 19:58:41 UTC+1, Adam Spiers wrote:

Hi all,

Firstly many thanks for all your awesome work on magit!  It is a massive help to me on a daily basis.

I just updated to the latest git version, and I see a big change in the workflow involved in making a commit.  Previously, four keystrokes (including Shift) would deal with the use case I need 90% of the time: `c' to drop me straight into the commit log buffer, and `C-c C-c' when I'd finished writing the commit log.

However, with the new workflow,

[list of gripes snipped]

Sorry - I also forgot to mention that rebasing also seems to have lost the incredibly useful dedicated mode where e.g. I could re-order commits via `M-n', `M-p', squash via `s', fixup via `f' etc.  Is this part of the same change?  How can I get this functionality back?  Thanks!

[Óscar Fuentes]

Adam Spiers <gro...@adamspiers.org> writes:

[...]

+1

From looking at recent activity on magit it seems to me that the current
workflow is here to stay. git-commit is fine for those who work on the
command line, but invoking emacsclient from magit is terrible.

[Nikolai Weibull]

On Fri, Aug 23, 2013 at 12:40 AM, Óscar Fuentes <o...@wanadoo.es> wrote:

> From looking at recent activity on magit it seems to me that the current
> workflow is here to stay. git-commit is fine for those who work on the
> command line, but invoking emacsclient from magit is terrible.

This is the mayor downside of discussing everything at Github instead
of the mailing list. We who don’t follow things on Github, given that
we have the mailing list, have no chance of submitting input on
upcoming changes.

This change seems like it’s a mayor step back, but perhaps it’s the
right thing to do. Either way, please make sure that Magit continues
to work in the terminal.

[Adam Spiers]

Why would it ever cease working in the terminal?

[Nikolai Weibull]

https://github.com/magit/magit/issues/786

[Adam Spiers]

[TL;DR summary at the end]

I've done some research to try and understand why these changes which
confused me quite a lot have been made to magit, and

https://github.com/magit/magit/issues/675

makes for interesting although difficult reading. I think it would be
great if more of these design discussions happened on this list rather
than in a pull request, since a threaded discussion is easier to
follow than a huge linear one.

That aside, and ignoring the many workflow-related comments about what
code should belong in which repositories in which github organisation,
there are some specific technical points regarding this latest change
in direction which it's taking me a while to understand.

Firstly, for the benefit of others as ignorant as me of the details of
these recent changes, and to check that my understanding is correct,
let me attempt to summarise the key points:

Based on https://github.com/magit/magit/issues/675#issuecomment-22445492
and onwards, it seems that

- `magit-log-edit-mode' was the mechanism magit used to provide for
making commits (the one where `c' immediately opened a new
buffer).

- `git-commit-mode' is the new mechanism. #675 also introduces
magit-key-mode-popup-committing which provides integration with it
via a pop-up menu, in line with many other existing magit
operations called magit-key-mode-popup-something.

The main motivation for switching seems to be (please correct me if
I'm wrong):

1. Consistency of interface.

2. Re-use existing functionality from git and other
non-magit-specific git modes instead of having to maintain
magit-specific code.

3. gcm is less buggy and more feature-complete.

4. Separation of concerns.

My thoughts on these:

1. Although it irks me a bit to have to type `c c' rather than `c'
in the most common use case, consistency is a worth goal and I
can probably get used to that without too much whinging.

2. Makes sense - I guess this can help share the maintenance burden.
IIUC this mainly refers to the git-modes repo which seems to have
been moved to the magit github org:

https://github.com/magit/git-modes/network/members

3. Fair enough.

4. Definitely a good reason.

So far, so good. But I feel that there are some significant flaws in
this change. I'll quote some key paragraphs from the above comment:

> There is one major difference between magit-log-edit-mode and git-commit-mode:
>
> magit-log-edit-mode (mle): The commit message is prepared in Emacs
> before a Git process is involved at all. Then the message is send
> to "git commit" on its standard input. Unfortunately that bypasses
> some git functionality.

What is unfortunate about this? It always worked great AFAICS.

> git-commit-mode (gcm): Magit calls git commit without a commit
> message as argument or on stdin. Git then used emacsclient
> .git/COMMIT_MSG ($GIT_EDITOR) to get the commit message. After
> emacsclient returns git resumes and creates the commit using the
> commit message saved in the file.
>
> The second approach is much saner as it avoids re-implementing git
> functionality (in a, as of now, in-complete and buggy fashion).

What was buggy or incomplete?

> To me this alone answers the question whether git-commit-mode is
> strictly better than the built-in mode.

Sorry, but I have to strongly disagree with "much saner" - calling
emacsclient from within emacs to open a new workflow inside the same
emacs seems pretty crazy to me ;-p It seems to have already created
several problems. I mentioned some here:

https://groups.google.com/d/msg/magit/ByE2qMC12hM/mAnJWmhhkwoJ

but it seems you already plan to fix them:

> Issues with gcm (likely trivial to fix):
>
> Aborting a commit results in a generic error from magit-run*.
> Use of emacsclient message mentions C-x #, we want C-c C-c and C-c C-k mentioned.

Other people have found problems too, e.g.

https://github.com/magit/magit/issues/772
https://github.com/magit/magit/issues/786
https://github.com/magit/magit/issues/805

Kudos for fixing some of these so quickly, but I wonder how many other
problems will be triggered by this weird design.

One aspect of it which did bother me a lot why I first tried it was
that when `git-commit-mode' invokes `git', it holds a lock on the git
repository which prevents certain operations from being performed
(e.g. from outside emacs). But I can't reproduce this now. Depending
on which operations the lock blocks, I guess it could actually be a
good feature.

TL;DR summary
-------------

Big changes rarely come without causing some pain, even when they are
done for good reasons. I don't mind the pain as long as it's
communicated transparently and expectations are clearly set in advance
of any upgrade. For that reason, I have filed a request to
reintroduce the NEWS file:

https://github.com/magit/magit/issues/807

Thanks for listening, and for your great work on magit!

[Eric Schulte]

Adam Spiers <gro...@adamspiers.org> writes:

[...]

> I think it would be great if more of these design discussions happened
> on this list rather than in a pull request, since a threaded
> discussion is easier to follow than a huge linear one.

+1 In my opinion, mailing lists are a better forum for development
discussion than the github pull request comment thread UI.

[...]

>
> - `magit-log-edit-mode' was the mechanism magit used to provide for
> making commits (the one where `c' immediately opened a new
> buffer).
>
> - `git-commit-mode' is the new mechanism. #675 also introduces
> magit-key-mode-popup-committing which provides integration with it
> via a pop-up menu, in line with many other existing magit
> operations called magit-key-mode-popup-something.
>

I used to use the following to customize my commit edit buffer to help
conform to git commit log style guidelines (first line <=50 chars and
all others <=73).

;; -*- emacs-lisp -*-
(add-hook 'magit-log-edit-mode-hook
(lambda ()
(column-marker-1 51)
(column-marker-3 73)
(set-fill-column 72)))

The commit edit log is now in `fundamental-mode', and I can find no hook
run when this buffer is opened. What would be the recommended way to
re-enable such customization?

Thanks,

--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

[Noam Postavsky]

On Sun, Aug 25, 2013 at 3:10 PM, Eric Schulte <schult...@gmail.com> wrote:
> The commit edit log is now in `fundamental-mode', and I can find no hook
> run when this buffer is opened. What would be the recommended way to
> re-enable such customization?

You can install git-commit-mode from github.com/magit/git-modes, which
is now a dependency of magit (along with git-rebase-mode):

(define-package "magit" "1.2.1-git"
"Control Git from Emacs."
'((cl-lib "0.3")
(git-commit-mode "0.14.0")
(git-rebase-mode "0.14.0")))

It runs git-commit-mode-hook (and fontifies the characters on the
first line past column 51 in git-commit-overlong-summary-face out of
the box).

[Eric Schulte]

Thanks, after installing these extra packages I can indeed use these
hooks.

The first line of the pre-populated git commit boilerplate is fontified
in the `git-commit-overlong-summary-face'. To be clear, my
COMMIT_EDITMSG buffer is opened with the following, and the second line
is all in red.

,----
|
| # Please enter the commit message for your changes. Lines starting
| # with '#' will be ignored, and an empty message aborts the commit.
| # On branch master
| # Changes to be committed:
| # (use "git reset HEAD <file>..." to unstage)
| #
`----

[Eric Schulte]

The attached patch fixes this bug.

[Phil Jackson]

Hey all,

When I wrote the current menu-popup system in Magit I implemented
a popup for commiting just like the one that's been built
here. People were generally happy with the popup menus elsewhere
but I pulled it out of commit because there was so much
resistance.

Before I quit Magit I had intended to keep the current workflow
but have a slightly nicer implementation of the
header-for-options system that served us reasonably well for all
this time.

My two cents; I'm not sure I like the new way. I find the menu is
obstructive in this instance.

Cheers,
Phil

[Adam Spiers]

Agreed Phil. The most common commit use case by far is surely "commit
without needing any special options", so to always pop up a menu
offering options is suboptimal for the majority of cases. Presumably
this is why there was so much resistance when you first introduced it.

[Alex Ott]

Another problem that I encounter with new commit workflow is that opening of new frame takes some time, and I usually press 'c' (and it's not a problem with 'c c' even) and start to type, but focus is still in magit buffer, so if I type like 'update something', then magit complains "nothing to unstage" because first character is entered not in commit buffer, but in magit buffer

--

---
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
With best wishes,                    Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

[Tom Davis]

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. There are definitely still
bugs (first line of commit message is in the wrong place, the commit
buffer doesn't close when the commit finishes, etc.) but all of these
are minor compared with the use cases enabled by the new commit
mechanism.

[Perry Smith]

On a Mac, finding emacsclient is not as easy as falling off a chair.

The way I build emacs on the Mac is to make an application. The path to emacsclient happens to be:

/Applications/Emacs.app/Contents/MacOS/bin/emacsclient

The other "ick" is invocation-directory is set to /Applications/Emacs.app/Contents/MacOS/ because (I'm half guessing) it is executing either Emacs or Emacs.sh found in that directory when you double click the icon. I've managed to fix this with the small change below.

(let ((version (format "%s.%s"
emacs-major-version
emacs-minor-version)))
(or (let ((exec-path (list invocation-directory (format "%sbin/" invocation-directory)))) <<<< changed.
(or (executable-find (format "emacsclient-%s" version))
(executable-find (format "emacsclient-%s.exe" version))
(executable-find "emacsclient")
(executable-find "emacsclient.exe")))
(executable-find (format "emacsclient-%s" version))
(executable-find (format "emacsclient-%s.exe" version))
(executable-find "emacsclient")
(executable-find "emacsclient.exe")))

(note that invocation-directory ends with a slash)

I can add this to a pull request if that would help out and if you think this is the way to fix it.

Thank you,
Perry

[Perry Smith]

But this could be said about most of the operations. "P P" to push. "F F" to pull.

On a different topic: do most folks bind 'magit-status' to a simpler key sequence?

I just did my first commit with the new work flow after fixing my Mac issue.
I assume there is good reason for all the changes (and I'm not
trying to be sarcastic) but I'm having some growing pains right now.

On a different different topic: emacs + git + magit is wonderful! Really. It
just feels so nice in so many ways.

Perry

[Adam Spiers]

On Thu, Aug 29, 2013 at 10:13:31AM -0400, Tom Davis wrote:
> gro...@adamspiers.org writes:
> > On 27 August 2013 14:40, Phil Jackson <ph...@shellarchive.co.uk> wrote:
> >> Hey all,
> >>
> >> When I wrote the current menu-popup system in Magit I implemented
> >> a popup for commiting just like the one that's been built
> >> here. People were generally happy with the popup menus elsewhere
> >> but I pulled it out of commit because there was so much
> >> resistance.
> >>
> >> Before I quit Magit I had intended to keep the current workflow
> >> but have a slightly nicer implementation of the
> >> header-for-options system that served us reasonably well for all
> >> this time.
> >>
> >> My two cents; I'm not sure I like the new way. I find the menu is
> >> obstructive in this instance.
> >
> > Agreed Phil. The most common commit use case by far is surely "commit
> > without needing any special options", so to always pop up a menu
> > offering options is suboptimal for the majority of cases. Presumably
> > this is why there was so much resistance when you first introduced it.
>
> 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.

Why not?

> There are definitely still
> bugs (first line of commit message is in the wrong place, the commit
> buffer doesn't close when the commit finishes, etc.) but all of these
> are minor compared with the use cases enabled by the new commit
> mechanism.

Which new use cases? I guess there are some which I missed. But even
so, that does not in itself justify introducing a popup menu, because
surely the new use cases could have been added to the old style of
interface?

[Adam Spiers]

On Thu, Aug 29, 2013 at 09:57:38AM -0500, Perry Smith wrote:
> On Aug 29, 2013, at 8:52 AM, Adam Spiers <gro...@adamspiers.org> wrote:
> > On 27 August 2013 14:40, Phil Jackson <ph...@shellarchive.co.uk> wrote:
> >> Hey all,
> >>
> >> When I wrote the current menu-popup system in Magit I implemented
> >> a popup for commiting just like the one that's been built
> >> here. People were generally happy with the popup menus elsewhere
> >> but I pulled it out of commit because there was so much
> >> resistance.
> >>
> >> Before I quit Magit I had intended to keep the current workflow
> >> but have a slightly nicer implementation of the
> >> header-for-options system that served us reasonably well for all
> >> this time.
> >>
> >> My two cents; I'm not sure I like the new way. I find the menu is
> >> obstructive in this instance.
> >
> > Agreed Phil. The most common commit use case by far is surely "commit
> > without needing any special options", so to always pop up a menu
> > offering options is suboptimal for the majority of cases. Presumably
> > this is why there was so much resistance when you first introduced it.
>
> But this could be said about most of the operations. "P P" to push. "F F" to pull.

I disagree - e.g. I *always* want to pause and think before issuing a
push. Allowing push via a single keystroke is far too dangerous.

> On a different topic: do most folks bind 'magit-status' to a simpler key sequence?

Yes, C-S-g here.

> On a different different topic: emacs + git + magit is wonderful! Really. It
> just feels so nice in so many ways.

Agreed! :-)

[Perry Smith]

On Aug 29, 2013, at 11:16 AM, Adam Spiers <gro...@adamspiers.org> wrote:

> On Thu, Aug 29, 2013 at 09:57:38AM -0500, Perry Smith wrote:
>> On Aug 29, 2013, at 8:52 AM, Adam Spiers <gro...@adamspiers.org> wrote:
>>> On 27 August 2013 14:40, Phil Jackson <ph...@shellarchive.co.uk> wrote:
>>>> Hey all,
>>

>> But this could be said about most of the operations. "P P" to push. "F F" to pull.
>
> I disagree - e.g. I *always* want to pause and think before issuing a
> push. Allowing push via a single keystroke is far too dangerous.

Yea. true. A single key for commit still allows you to stop and think / back out.

[Tom Davis]

gro...@adamspiers.org writes:

> On Thu, Aug 29, 2013 at 10:13:31AM -0400, Tom Davis wrote:
>> gro...@adamspiers.org writes:
>> > On 27 August 2013 14:40, Phil Jackson <ph...@shellarchive.co.uk> wrote:
>> >> Hey all,
>> >>
>> >> When I wrote the current menu-popup system in Magit I implemented
>> >> a popup for commiting just like the one that's been built
>> >> here. People were generally happy with the popup menus elsewhere
>> >> but I pulled it out of commit because there was so much
>> >> resistance.
>> >>
>> >> Before I quit Magit I had intended to keep the current workflow
>> >> but have a slightly nicer implementation of the
>> >> header-for-options system that served us reasonably well for all
>> >> this time.
>> >>
>> >> My two cents; I'm not sure I like the new way. I find the menu is
>> >> obstructive in this instance.
>> >
>> > Agreed Phil. The most common commit use case by far is surely "commit
>> > without needing any special options", so to always pop up a menu
>> > offering options is suboptimal for the majority of cases. Presumably
>> > this is why there was so much resistance when you first introduced it.
>>
>> 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.
>
> Why not?
>

Because when you need to pass "-n" to "git commit" and you can't, you
can't commit.

>
>> There are definitely still
>> bugs (first line of commit message is in the wrong place, the commit
>> buffer doesn't close when the commit finishes, etc.) but all of these
>> are minor compared with the use cases enabled by the new commit
>> mechanism.
>
> Which new use cases? I guess there are some which I missed. But even
> so, that does not in itself justify introducing a popup menu, because
> surely the new use cases could have been added to the old style of
> interface?

Perhaps, but the header-style interface to commits was different from
all other commands that include options, AFAIK. Discovery is also a
concern; if you add, e.g., "C-c C-n" as another commit header thingy,
the only way to find that would be via the mode help. Hell, maybe it did
get added and I never knew ;)

[Adam Spiers]

I see. I never needed that personally, but totally understand ;-)

> >> There are definitely still
> >> bugs (first line of commit message is in the wrong place, the commit
> >> buffer doesn't close when the commit finishes, etc.) but all of these
> >> are minor compared with the use cases enabled by the new commit
> >> mechanism.
> >
> > Which new use cases? I guess there are some which I missed. But even
> > so, that does not in itself justify introducing a popup menu, because
> > surely the new use cases could have been added to the old style of
> > interface?
>
> Perhaps, but the header-style interface to commits was different from
> all other commands that include options, AFAIK.

True, but we shouldn't let the quest for consistency get in the way of
the quest for the best interface :-)

> Discovery is also a concern; if you add, e.g., "C-c C-n" as another
> commit header thingy, the only way to find that would be via the
> mode help. Hell, maybe it did get added and I never knew ;)

That's a very good point. However, it should be easy to discover such
things by reading the manual, and prioritising catering for newbies
over catering for experienced users is a slippery slope. Almost by
definition, anyone who uses git + emacs + magit is an advanced user
who is likely to invest time in learning their tools properly ;-)

I think the most telling evidence is that Phil mentioned he already
added a popup menu for commit in the past, but then had to withdraw it
due to large resistance. Surely we can learn from previous
experiences?

That said, the ideal world would be a M-x customize-option allowing a
choice between `c' immediately progressing to the commit buffer, or
popping up a menu. If that existed, I wouldn't really mind what the
default setting was :-) This is very similar to the request here:

https://github.com/magit/magit/issues/826

although personally I would prefer to see both options use
git-commit-mode. Having to maintain two separate commit modes
indefinitely would seem like the worst possible outcome.

[Jonas Bernoulli]

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
obstructive in this instance.

I was quite surprised by the (current) resistance to that feature, as I personally have no problem with pressing "c c" instead of "c" and having the popup shortly flashing by.

But since many people disagree I will add an option to restore the old behavior as much as possible. The option will control whether the message comes up immediately or if one has to go through the popup to get there. A prefix argument will allow doing "the other thing".

There is now way to restore the "toggle between amend and regular commit" while editing the message. So the prefix argument is essential.

[Jonas Bernoulli]

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 one person beside me! :-)

 

There are definitely still bugs

Working hard here and getting these sorted out.

There is also some lost functionality that hasn't been mentioned by anyone yet. Which needs to be restored. 

[Eric Schulte]

Why not have `c' open the commit buffer directly, and `c' with a prefix
argument (i.e. `C-u c') could open up the full option menu. In fact I
would recommend this as the default for *all* magit commands (dangerous
commands would probably want to be wrapped in a y-or-n-p).

This would be efficient and convenient, provide for internal consistency
within magit and this would be consistent with how Emacs at large
handles optional command customization. To new users who have used
Emacs before this should be the obvious thing to try.

If there is any interest I'd be happy to put together a patch, given
magit's very nice meta-programmed action mechanisms it seems like it
should be a small change... very easy to implement, attached.

[Jonas Bernoulli]

I am VERY SORRY to have caused this breakage and I am taking full responsibility.

The move to git-commit-mode was premature. I intended to keep magit-log-edit as a fallback or possibly even as the default but was talked out of it. I should have followed my intuition by playing it safe instead of listening to those who said that wasn't necessary. It is my mistake that I did not do so.

I am working hard to fix the regressions. Unfortunately that also means that I don't have time yet to implement features that take advantage of the new workflow. There are some unexploited benefits that are currently hidden below all the regressions.

Some of the drawbacks of the new workflow will vanish after making overdue changes elsewhere. But some drawbacks are inherent to the use of emacsclient.

Because fixing the regressions is taking longer than I had originally expected 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

[Eric Schulte]

> Why not have `c' open the commit buffer directly, and `c' with a prefix
> argument (i.e. `C-u c') could open up the full option menu. In fact I
> would recommend this as the default for *all* magit commands (dangerous
> commands would probably want to be wrapped in a y-or-n-p).
>
> This would be efficient and convenient, provide for internal consistency
> within magit and this would be consistent with how Emacs at large
> handles optional command customization. To new users who have used
> Emacs before this should be the obvious thing to try.
>
> If there is any interest I'd be happy to put together a patch, given
> magit's very nice meta-programmed action mechanisms it seems like it
> should be a small change... very easy to implement, attached.
>

I'm happy to hear that something along these lines will be adopted.

Having used my previous patch for an hour or so I'm finding this
prefix-argument tact matches very well with my own personal Emacs-warped
muscle memory. If it's useful I'm attaching an improved version of the
previous patch.

[Adam Spiers]

Hey Jonas, don't beat yourself up too much :-) We don't live in a
perfect world, and things always go wrong. In the grand scheme of
things, this is really not a disaster - just a minor inconvenience for
a few geeks ;-) The important thing is we learn from our *collective*
mistakes (noone should claim this is the fault of a single person) and
move on together in the right direction as a community. And it is
clear that you are very focused on fixing things whilst listening
carefully to the community. Noone can ask for more from a maintainer,
and I for one am very grateful for your efforts. magit is a great
piece of software and I'm excited to see what happens over the next
few months and years!

Adam

[Perry Smith]

Ditto...

<from another thread>
>> 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.

Things like this ^^^ are really awesome and it seems always comes at some price.

I wish I could do more to help.

pedz

[Óscar Fuentes]

Eric Schulte <schult...@gmail.com>
writes:

I strongly oppose this change. For committing 99% of the time you want
what now is `c c' but for other commands (log, branch) it is common to
use a command variant (actually, `b' is a gateway for a group of
different commands.) Pressing `C-u b v' for entering the branch manager
or `C-u l L' for Long Log is anything but efficient. The key-groups
design already allowed for the "most common variant" by assigning it the
same letter as the key-group trigger (`l l', `b b', etc.) This
introduced a negligible delay in exchange for lots of flexibility and
grow space.

Seriously, I can't see what's so inefficient with pressing an extra `c'
for committing. Two tenths of a second for an operation that culminates
a task that typically takes a minimum of several minutes? C'mon!

It is true that `c c' faced enough resistance to ditch it. But the whole
key-groups feature faced that same resistance and it survived, simply
because Magit was running out of keys and there was a nightmare of
command-prefix tricks (uh!) for accessing just a few of the most common
options (all the rest be damned, as well as their combinations.) It
could be said that `c c' was reverted to plain `c' just because
committing has no variants (as logging does) and the options for `git
commit' were not popular enough.

[Marius Vollmer]

Jonas Bernoulli <jonasbe...@gmail.com> writes:

> Some of the drawbacks of the new workflow will vanish after making overdue
> changes elsewhere. But some drawbacks are inherent to the use of
> emacsclient.

Using emacsclient strikes me as wrong. If I understand things right
from reading this list, you want Git to prepare the content of the
commit message. Couldn't that be done by piping "git commit --dry-run"
into the buffer?

[Rémi Vanicat]

Óscar Fuentes <ofv-39ZsbGIQG...@public.gmane.org> writes:


[...]

>>
>> I'm happy to hear that something along these lines will be adopted.
>>
>> Having used my previous patch for an hour or so I'm finding this
>> prefix-argument tact matches very well with my own personal Emacs-warped
>> muscle memory. If it's useful I'm attaching an improved version of the
>> previous patch.
>
> I strongly oppose this change. For committing 99% of the time you want
> what now is `c c' but for other commands (log, branch) it is common to
> use a command variant (actually, `b' is a gateway for a group of
> different commands.) Pressing `C-u b v' for entering the branch manager
> or `C-u l L' for Long Log is anything but efficient. The key-groups
> design already allowed for the "most common variant" by assigning it the
> same letter as the key-group trigger (`l l', `b b', etc.) This
> introduced a negligible delay in exchange for lots of flexibility and
> grow space.
>
> Seriously, I can't see what's so inefficient with pressing an extra `c'
> for committing. Two tenths of a second for an operation that culminates

e> a task that typically takes a minimum of several minutes? C'mon!

I agree with this. I like the flexibility of the key-group as they are
now. And what is the matter with 'c c'? it only one key, and the same
one...

--
Rémi Vanicat

[Nikolai Weibull]

On Fri, Aug 30, 2013 at 8:41 AM, Rémi Vanicat <van...@debian.org> wrote:
> Óscar Fuentes <ofv-39ZsbGIQG...@public.gmane.org> writes:
>
>> Seriously, I can't see what's so inefficient with pressing an extra `c'
>> for committing. Two tenths of a second for an operation that culminates
> e> a task that typically takes a minimum of several minutes? C'mon!
>
> I agree with this. I like the flexibility of the key-group as they are
> now. And what is the matter with 'c c'? it only one key, and the same
> one...

When you want to push your commits you press P, then you consider if
there are any options that you want to specify. After having
considered this you press P again.

When you want to commit your changes you press c, then you consider
what those changes are and write an appropriate message. After having
done this you press C-c C-c.

Thus, for commits, the message buffer is your pause area. Here you
write your message, toggle options, and so on. For push, there’s no
buffer, but an options menu.

Having these tasks be consistent in how they’re executed can actually
hurt more than it helps. Consider that you almost always will press c
c when you commit. You’ll soon develop a habit that can easily infect
your habit of pausing after P and just press P P without thinking
things through first.

If, however, we’re set on using the new commit workflow of invoking
git-commit immediately and using emacsclient, then this whole
discussion is moot, as we’ll have to be able to specify options before
we begin, rather than during/after.

[Eric Schulte]

Fair enough. While I disagree that pressing command keys twice is
negligible, and I spend no where near several minutes writing my commit
messages, we probably just have different commit styles.

Perhaps a workable middle ground acknowledging such personal differences
would be to introduce a variable (say `magit-immediate-commands') which
controls which commands run immediately by default, and all other
commands could open the option dialog. Calling any command with a
prefix argument could then do the opposite of the default (e.g., open
option pane or run immediately). This variable could initially just be
set to '(committing) so that new users are exposed to the options.

The attached patch implements such a solution. In addition it changes
the default action from "first listed" to "one with the same key stroke
as the action". Please try it out and let me know what you think.

[Óscar Fuentes]

Eric Schulte <schult...@gmail.com>
writes:

> Fair enough. While I disagree that pressing command keys twice is
> negligible, and I spend no where near several minutes writing my commit
> messages, we probably just have different commit styles.

It takes at least several minutes to create the changes that you plan to
commit. Writing the commit message is just a final chore.

> Perhaps a workable middle ground acknowledging such personal differences
> would be to introduce a variable (say `magit-immediate-commands') which
> controls which commands run immediately by default, and all other
> commands could open the option dialog.

IIRC there was an "old-magit compatibility special mode" for those who
disliked key-groups. Maybe it was removed, dunno. I'm fine with your
proposal as long as it is opt-in. After all, I will not use it nor I had
to maintain the code ;-)

[snip]

[Óscar Fuentes]

Nikolai Weibull <n...@disu.se> writes:

> When you want to push your commits you press P, then you consider if
> there are any options that you want to specify. After having
> considered this you press P again.
>
> When you want to commit your changes you press c, then you consider
> what those changes are and write an appropriate message. After having
> done this you press C-c C-c.
>
> Thus, for commits, the message buffer is your pause area. Here you
> write your message, toggle options, and so on. For push, there’s no
> buffer, but an options menu.
>
> Having these tasks be consistent in how they’re executed can actually
> hurt more than it helps. Consider that you almost always will press c
> c when you commit. You’ll soon develop a habit that can easily infect
> your habit of pausing after P and just press P P without thinking
> things through first.

The key-groups popup is not a "pause area" by any stretch. I press `ll'
for `short log' all the time, `bb' for `check out', `ff' for `fetch'
and... `PP' for `push' without pausing at all. If key-groups does
anything on the "protecting users from their own mistakes" area is to
require two key presses instead of one, that's all. If you are afraid of
accidentally pushing your changes some other mechanism should be
implemented.

Actually, I share your concerns about accidental pushes (among other
operations) and something like requiring to type a random string (let's
say two letters) just before the command executes, is something I'll
use. As an opt-in feature, of course.

[snip]

[Adam Spiers]

On Fri, Aug 30, 2013 at 04:09:21AM +0200, �scar Fuentes wrote:
> I strongly oppose this change. For committing 99% of the time you want
> what now is `c c' but for other commands (log, branch) it is common to
> use a command variant (actually, `b' is a gateway for a group of
> different commands.) Pressing `C-u b v' for entering the branch manager
> or `C-u l L' for Long Log is anything but efficient.
>
> The key-groups
> design already allowed for the "most common variant" by assigning it the
> same letter as the key-group trigger (`l l', `b b', etc.) This
> introduced a negligible delay in exchange for lots of flexibility and
> grow space.
>
> Seriously, I can't see what's so inefficient with pressing an extra `c'
> for committing. Two tenths of a second for an operation that culminates
> a task that typically takes a minimum of several minutes? C'mon!
>
> It is true that `c c' faced enough resistance to ditch it. But the whole
> key-groups feature faced that same resistance and it survived, simply
> because Magit was running out of keys and there was a nightmare of
> command-prefix tricks (uh!) for accessing just a few of the most common
> options (all the rest be damned, as well as their combinations.) It
> could be said that `c c' was reverted to plain `c' just because
> committing has no variants (as logging does) and the options for `git
> commit' were not popular enough.

I agree that a popup menu is much nicer than arcane prefix tricks.
For me, the big issue is not so much whether it is required to press
`c' once or twice, since that's mainly a muscle memory thing which can
be re-learned. The real issue is how magit invokes git. Triggering
emacsclient via git commit *before* the user starts composing the log
message creates all kinds of problems, some of which are detailed in
the issue I filed yesterday:

https://github.com/magit/magit/issues/827

These issues could perhaps be characterized by observing that the new
commit workflow sets an expectation that once the commit log buffer
opens for editing, magit expects that you will complete or abort the
commit before you do *anything* else. In other words, it's a bit like
popping up a modal dialog box which stops you interacting with any of
the windows behind it, except it's worse, because in this case it
*doesn't* stop you switching windows even though that can result in
broken behaviour.

The emacs UI is famously non-modal in design, and this is a Good
Thing. For example, read what Steve Yegge has to say about dialog
boxes in item 6 of this article:

https://sites.google.com/site/steveyegge2/effective-emacs

I guess these considerations are probably the root cause of my
instinctive "ugh" reaction to the use of emacsclient. Using
emacsclient to invoke emacs from within emacs just seems pretty insane
to me - an ugly hack done to avoid some cleaner solution. It's a bit
like some kind of network-based daemon which talks to itself via TCP.
(No doubt someone will now produce a counter-example where this is
actually a good idea ;-)

Like Marius points out, if you want git to prepare the content of the
commit message, that can be done by piping "git commit --dry-run" into
the buffer. So I simply don't understand the motivation for using
emacsclient and this pseudo-modal approach. What am I missing?

Whilst the commit log buffer is pseudo-modal, the popup menus are also
modal - even more so. Ideally that should be fixed in the future so
that the popups appear in a 1st class buffer and do not stop you
performing other operations whilst a popup menu is visible. But IMHO
this is not too evil as it stands right now for tasks like 'push'
which cannot possibly proceed without specifying further parameters
for how the push should be done.

[Adam Spiers]

On Fri, Aug 30, 2013 at 11:05:45AM +0200, �scar Fuentes wrote:
> Eric Schulte <schult...@gmail.com> writes:
> > Fair enough. While I disagree that pressing command keys twice is
> > negligible, and I spend no where near several minutes writing my commit
> > messages, we probably just have different commit styles.
>
> It takes at least several minutes to create the changes that you plan to
> commit. Writing the commit message is just a final chore.

That's an inaccurate generalization. Sometimes writing the commit
message can take much longer than the change, and also sometimes it's
easier to write the commit message incrementally whilst you are
working on the change. Such a long-lived commit workflow is another
reason to avoid the modal approach to committing.

> > Perhaps a workable middle ground acknowledging such personal differences
> > would be to introduce a variable (say `magit-immediate-commands') which
> > controls which commands run immediately by default, and all other
> > commands could open the option dialog.

The problem is that with the current commit implementation, you have
to decide which commit options you want *before* you even start
writing the log file. The "long-lived commit buffer" use case above
is one example of why this is a bad idea.

[Adam Spiers]

Amen!

[Rémi Vanicat]

git commit --dry-run don't run git's pre-commit-hook nor
prepare-commit-msg:

% ln -s /bin/false .git/hooks/pre-commit
% git commit
% git commit --dry-run
# Sur la branche master
# Modifications qui seront validées :
[...]

You can see that running git commit just fail because the pre-commit
failed, but dry-run do print its result.

Note also that if emacsclient bother you so much, there is already what
is needed for magit to not run it:

(setq magit-emacsclient-executable nil)

--
Rémi Vanicat

[Rémi Vanicat]

Nikolai Weibull <now-yvQ...@public.gmane.org> writes:

> On Fri, Aug 30, 2013 at 8:41 AM, Rémi Vanicat <vanicat-8fiUuRr...@public.gmane.org> wrote:
>> Óscar Fuentes <ofv-39ZsbGIQGT7e5aOfsHch...@public.gmane.org> writes:
>>
>>> Seriously, I can't see what's so inefficient with pressing an extra `c'
>>> for committing. Two tenths of a second for an operation that culminates
>> e> a task that typically takes a minimum of several minutes? C'mon!
>>
>> I agree with this. I like the flexibility of the key-group as they are
>> now. And what is the matter with 'c c'? it only one key, and the same
>> one...
>
> When you want to push your commits you press P, then you consider if
> there are any options that you want to specify. After having
> considered this you press P again.

No, when I push, I do P P and then sometime say "#***!!, it is not what I wanted to
push.

[...]


--
Rémi Vanicat

[Alex Ott]

with (setq magit-emacsclient-executable nil) the magit buffer isn't updated after commit is 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+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
With best wishes,                    Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

[Óscar Fuentes]

Rémi Vanicat <van...@debian.org> writes:

> No, when I push, I do P P and then sometime say "#***!!, it is not
> what I wanted to push.

This might help:

(add-hook 'magit-push-command-hook
(lambda ()
(not (yes-or-no-p "Are you sure you wish to push? "))))

[Frank Terbeck]

Adam Spiers wrote:
> Firstly many thanks for all your awesome work on magit! It is a massive
> help to me on a daily basis.

Indeed.

> I just updated to the latest git version, and I see a big change in the
[...]

I also updated to the git version, because I updated to a recent emacs
snapshot on my laptop, which didn't really feel like working with the
magit version from ELPA. The git version fixes that, so here I am. :)

> However, with the new workflow, there is an extra commit options menu I
[...]

Personally, I don't mind the extra pop-up. "c c" or "c"... doesn't make
much of a difference to me.

Here is one (or rather two) issue(s), I'm seeing:

- I mainly use emacs in terminals. The GUI version (with enabled emacs
server mode) didn't present these issues to me.

- In the status-buffer, I stage some changes, and hit "c c". Now I'm
dropped into a log-editing buffer with some _older_ commit message.
In the GUI version of emacs I was dropped into a buffer, that had a
descriptive comment preloaded - I suppose that's the intended
behaviour. This is the first issue.

- Editing the commit message went fine otherwise. The highlighting
makes sense; and things like "C-c C-s" for adding a Signed-off tag
worked as well.

- Now, when I'm done I hit "C-c C-c" (not "C-c #" like in the GUI
version, I don't even try to enable server-mode in a terminal
emacs - so there's no point in using `server-edit'), and it sure
proceeds with the commit and kills the editing window. Good. But
before, it also switched back to the magit-status buffer and
_refreshed_ it. This doesn't happen in my terminal emacs sessions
anymore, which is rather inconvenient. (In the GUI version, I used
"C-x #" to invoke `server-edit' and then everything was switched
around and refreshed like I expected.) - This is the 2nd issue.

So, that's what I found.

I skimmed through the thread so far and I think I didn't see these
issues being reported yet. I may have missed something. Or maybe they
were reported to your bug-tracker over at github. If so, I apologise for
not looking close enough. In that case, please point me to the relevant
discussion.


Regards, Frank

--
There are no threads in alt.binaries.pictures.erotica,
so there's no gain in using a threaded news reader.
-- unknown source

[Jonas Bernoulli]

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 recommend anyone uses it, I only added it for the benefit of people already used to `magit-keys.el'.

[Adam Spiers]

On Fri, Aug 30, 2013 at 02:50:57PM +0200, R�mi Vanicat wrote:
> Marius Vollmer <marius....@redhat.com> writes:
>
> > Jonas Bernoulli <jonasbe...@gmail.com> writes:
> >
> >> Some of the drawbacks of the new workflow will vanish after making overdue
> >> changes elsewhere. But some drawbacks are inherent to the use of
> >> emacsclient.
> >
> > Using emacsclient strikes me as wrong. If I understand things right
> > from reading this list, you want Git to prepare the content of the
> > commit message. Couldn't that be done by piping "git commit --dry-run"
> > into the buffer?
>
> git commit --dry-run don't run git's pre-commit-hook nor
> prepare-commit-msg:
>
> % ln -s /bin/false .git/hooks/pre-commit
> % git commit
> % git commit --dry-run
> # Sur la branche master

> # Modifications qui seront valid�es :

> [...]
>
> You can see that running git commit just fail because the pre-commit
> failed, but dry-run do print its result.

Is it really necessary to run pre-commit-hook whilst preparing a
commit log buffer? Normally that hook is used for validation tests,
e.g. checking code style or running unit tests, right? So it's enough
for those to be run when the real commit happens.

Obviously prepare-commit-msg needs to be run, and it's arguably a
missing feature in git that commit --dry-run can't run it, but
presumably it's trivial to work around that shortcoming by running it
manually?

> Note also that if emacsclient bother you so much, there is already what
> is needed for magit to not run it:
>
> (setq magit-emacsclient-executable nil)

Really? "git grep magit-emacsclient-executable" in my magit repo
yields no matches, nor does my running emacs have any awareness of
that variable.

[Rémi Vanicat]

Frank Terbeck <f...@bewatermyfriend.org> writes:

> Adam Spiers wrote:
>> Firstly many thanks for all your awesome work on magit! It is a massive
>> help to me on a daily basis.
>
> Indeed.
>
>> I just updated to the latest git version, and I see a big change in the
> [...]
>
> I also updated to the git version, because I updated to a recent emacs
> snapshot on my laptop, which didn't really feel like working with the
> magit version from ELPA. The git version fixes that, so here I am. :)
>
>> However, with the new workflow, there is an extra commit options menu I
> [...]
>
> Personally, I don't mind the extra pop-up. "c c" or "c"... doesn't make
> much of a difference to me.
>
> Here is one (or rather two) issue(s), I'm seeing:
>

[...]

>
> So, that's what I found.
>
> I skimmed through the thread so far and I think I didn't see these
> issues being reported yet. I may have missed something. Or maybe they
> were reported to your bug-tracker over at github. If so, I apologise for
> not looking close enough. In that case, please point me to the relevant
> discussion.

I believe that it is what Jonas describe as "serious quirks" in
https://github.com/magit/magit/issues/801

I've added a link to your message their as reference.
--
Rémi Vanicat

[Rémi Vanicat]

Adam Spiers <gro...@adamspiers.org> writes:

[...]

> Is it really necessary to run pre-commit-hook whilst preparing a
> commit log buffer? Normally that hook is used for validation tests,
> e.g. checking code style or running unit tests, right? So it's enough
> for those to be run when the real commit happens.

Yes.

>
> Obviously prepare-commit-msg needs to be run, and it's arguably a
> missing feature in git that commit --dry-run can't run it, but
> presumably it's trivial to work around that shortcoming by running it
> manually?

Yes. But there are others: we don't take care of the commit.template git
config, and probably some more.

One of our goals was to not do all this by hand, but to let git do
it. By using git, we even implement feature not yet in git: they will be
available at once, when git will have them.

Mmm, I've perhaps one interesting solution: we can run

EDITOR=/bin/false git commit

git gererate the .git/COMMIT_EDITMSG, and we can use it to do watever is
needed. I will have to test this.

>
>> Note also that if emacsclient bother you so much, there is already what
>> is needed for magit to not run it:
>>
>> (setq magit-emacsclient-executable nil)
>
> Really? "git grep magit-emacsclient-executable" in my magit repo
> yields no matches, nor does my running emacs have any awareness of
> that variable.

strange, here, with a55e3f5402529d9b96b7c360eb6fdcbf61da49f3, I have

% git grep magit-emacsclient-executable
magit.el:(defcustom magit-emacsclient-executable
magit.el: (concat magit-emacsclient-executable
magit.el: (and magit-emacsclient-executable
magit.el: (unless magit-emacsclient-executable
magit.el: (error "Cannot %s when `magit-emacsclient-executable' is nil" action))

It's relatively recent, on of the several fix uses for the problems due
to this change.
--
Rémi Vanicat

[Eric Schulte]

NOTE: this email only addresses key-binding issues, not the potentially
more serious emacsclient issues which both appear in this thread.

It *is* opt in as you have to customize `magit-immediate-commands'
(which could be set to `nil' by default) to use it. The maintenance
burden of ~15 new lines in `magit-key-mode-generate' should be nil.

While this is certainly not the most important issue, I think the
ability to avoid pop-up menus for very common actions is worth the extra
configuration variable.

Cheers,

--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

[Marius Vollmer]

Rémi Vanicat <remi.v...@gmail.com> writes:

> Marius Vollmer <marius....@redhat.com> writes:
>
>> Using emacsclient strikes me as wrong. If I understand things right
>> from reading this list, you want Git to prepare the content of the
>> commit message. Couldn't that be done by piping "git commit --dry-run"
>> into the buffer?
>
> git commit --dry-run don't run git's pre-commit-hook nor
> prepare-commit-msg:

I see. Hmm. Previously, the pre-commit-hook would run when hitting
'C-c C-c' after writing the message, and now it should run when hitting
'c', before writing it.

As Adam says, this is quite a big change to the commit work flow, since
hitting 'c' (or 'cc') used to just switch buffers, and now it runs some
hooks that might take some time, produce potentially interesting output,
and might even fail.

Maybe there can be a new key binding that runs the pre-commit-hook
explicitly?

> Note also that if emacsclient bother you so much, [...]

Well, it seems to have caused a ton of regressions in the way it is used
and I have a hunch that it will continue to come back to bite us in the
ass for a long time.

What about running git twice for a commit? Once to run all the pre-
hooks and prepare the commit message, and a second time to actually do
the commit, without running any pre-hooks?

This seems to produce the commit message in "foo"

EDITOR=/bin/cat git commit >foo

and "--no-verify" can be used to skip the pre-commit hook on the actual
commit, if that is desired.

[Rémi Vanicat]

Marius Vollmer <marius....@redhat.com> writes:

[...]

> What about running git twice for a commit? Once to run all the pre-
> hooks and prepare the commit message, and a second time to actually do
> the commit, without running any pre-hooks?
>
> This seems to produce the commit message in "foo"
>
> EDITOR=/bin/cat git commit >foo

the bin/cat editor won't be available on all computer (think
windows). That said I won't be surprised if cat was part of all windows
git distribution, we only have to find it.

This is why I prefer to use the /this/path/do/no/exist editor, that do
exists nowhere, and always let the message in .git/COMMIT_MGS, (but that
break somehow with my vcsh bindings... But it's another problem).

(One a side note: we need to send github message here, I feel like
speaking to mostly the same people on different channel, and it some
time fail to contact some of them)

But those detail aside, I like this solution.

Jonas proposed solution (use some waiting pseudo editor, a spoke of it
there: https://github.com/magit/magit/issues/801#issuecomment-23566863)
Could also be a solution, but as the emacsclient solution, it lock git
and magit in mid commit state.

> and "--no-verify" can be used to skip the pre-commit hook on the actual
> commit, if that is desired.

Mmm, if we didn't lock staging and other git operation while editing the
commit message, I tend to believe that hooks have to be run again.

--
Rémi Vanicat

[Phil Jackson]

All,

Thought I should follow up on this now that I've used it a little
more.

On 27 August 2013 14:40, Phil Jackson <ph...@shellarchive.co.uk> wrote:

[...]

> My two cents; I'm not sure I like the new way. I find the menu is
> obstructive in this instance.

I like the new behaviour much better now - when the menu stuff
first happened I was getting annoyed with people complaining
simply because their muscle memory had been interrupted. I was
doing the same when I posted above.

Appreciate all of the hard work that's continued on Magit,
especially recently.

Cheers,
Phil

[Jonas Bernoulli]

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 problem please report them in *its* issue tracker on github.

[Eric Schulte]

I've submitted two pull requests which address some of the issues from
this thread.

Roughly two months ago I submitted a pull request [1] which fixes the
inability of magit to perform any git actions while a commit is in
progress (more generally it allows multiple concurrent git processes).

I've just submitted a second pull request [2] adding a new customization
variable which may be used to specify default flags [3] or to skip the
magit command pop-up window entirely [4].

These changes address some of the issues from this thread and are both
available from the following repo [5] which applies them over top of the
current head. I'm announcing these here in case anyone else wants this
functionality while the magit maintainers decide whether or not to apply
these changes and/or while they implement their own versions.

I hope this is helpful,

Footnotes:
[1] https://github.com/magit/magit/pull/846

[2] https://github.com/magit/magit/pull/1008

[3] e.g., to always enable to -v option to commit add the following to
your config (or set through the customization interface)

(add-to-list 'magit-command-defaults
'(committing nil ("--verbose")))
(magit-key-mode-generate 'committing)

[4] e.g., to skip the pop-up window when committing add the following
to your config (or set through the customization interface)

;; assuming there is already a committing entry in
;; the `magit-command-defaults' alist
(setf (nth 1 (assoc 'committing magit-command-defaults))
magit-commit)
(magit-key-mode-generate 'committing)

[5] https://github.com/eschulte/magit/tree/eschulte

[Samuel Bronson]

On Sunday, October 20, 2013 10:30:29 AM UTC-4, Jonas Bernoulli wrote:
> 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.

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 ...

(Also, I find this new habit of sticking vital portions of magit in separate repositories distressing...)

[Jonas Bernoulli]

nae...@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 distressing...)

I find exaggerated claims to be distressing.

[Lele Gaifax]

Hi all,

this morning I installed the "next" branch of magit, together with
git-modes. I tried several variations, but I'm still unable to get it
correctly loaded, due to the following error:

Loading magit-blame...
load: Symbol's value as variable is void: magit-blame-popup

AFAICT, that symbol get defined by magit-blame.el, although later in the
source than its first reference... I don't speak list enough to say if
that's the problem though.

To get it going, I commented out the (require 'magit-blame) in
magit.el. I wonder if I'm doing something wrong.

Another thing that I tried without success is to set the default value
of the --verbose switch: I saw the new "C-c C-c" and "C-x C-s" bindings
in the commit popup menu, but apparently they didn't alter my custom
variables. How can I deduct the right variable name from the popup
definition?

Other than that, the next branch seems much faster on the operations I
do regularly, thank you a lot!

ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
le...@metapensiero.it | -- Fortunato Depero, 1929.

[Lele Gaifax]

Lele Gaifax <le...@metapensiero.it> writes:

> this morning I installed the "next" branch of magit, together with
> git-modes. I tried several variations, but I'm still unable to get it
> correctly loaded, due to the following error:
>
> Loading magit-blame...
> load: Symbol's value as variable is void: magit-blame-popup
>
> AFAICT, that symbol get defined by magit-blame.el, although later in the
> source than its first reference... I don't speak list enough to say if
> that's the problem though.
>
> To get it going, I commented out the (require 'magit-blame) in
> magit.el. I wonder if I'm doing something wrong.

Moving the definition of magit-blame-popup earlier in the code, before
it gets referenced by magit-blame-mode-map, fixed the issue.

[Jonas Bernoulli]

> 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 keymap is used, which in this case can only happen after
all of `magit-blame.el' has been loaded.

[Lele Gaifax]

I see. But them, how comes that I'm unable to load the pristine source
of magit-blame.el? To be precise, it does not compile cleanly, giving
the error I reported. After loading the package, most magit operations
fails with the same error... As said, maybe I'm doing something wrong,
but having tried several times to install/reinstall the whole package
from the git next branch, I failed to see the light.

thank you&ciao, lele.