[TL;DR summary at the end] On Thu, Aug 22, 2013 at 12:02:46PM -0700, Adam Spiers wrote: > On Thursday, 22 August 2013 19:58:41 UTC+1, Adam Spiers wrote: > > 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!
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! -- --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
