You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The library add-log, which is part of Emacs allows semi-automatically creating ChangeLog files. I think this library addresses a very real need, but does so in a highly inefficient and restrictive way.
A few years back there was a period where many users requested that similar features be implemented in Magit and my position was that, this should be done by improving add-log and Magit would then use that improved add-log. (I wasn't the only one who thought that this would be a good idea, see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16301.)
Unfortunately nobody stepped up to improve that library, so I am now entertaining to do it myself or to write an alternative from scratch if I come to the conclusion that is more efficient and or that my improvements are likely to be rejected by the Emacs maintainers on grounds of them being to invasive.
Currently Magit does wrap add-log to provide the following commands:
magit-commit-add-log Add a stub for the current change into the commit message buffer. If no commit is in progress, then initiate it.
magit-add-change-log-entry Find change log file and add date entry and item for current change. This differs from add-change-log-entry (which see) in that it acts on the current hunk in a Magit buffer instead of on a position in a file-visiting buffer.
magit-add-change-log-entry-other-window Find change log file in other window and add entry and item.
I don't think the latter two commands make much sense in the age of Git. ChangeLog are now used for high-level descriptions of the changes and the extensive log can be found in the commit messages. But they will remain, just in case someone actually uses them.
But magit-commit-add-log isn't really all that useful either. It does not generate and insert a list of changed changes. Instead the user has to go to each change in the diff and say "and for that change too, add a stub to the commit message".
The functionality should be split like so:
Generate a list of all changed symbols.
Format the list according to some preference.
Insert the formatted list somewhere.
Currently add-log does not clearly separate these tasks and, if I remember correctly it doesn't do (1) at all. But that's the most essential part.
Once (1) exists (in add-log.el or some other library), Magit will provide one function that can be added to git-commit-setup-hook to automatically insert the list of modified symbols. Users will be able to select from multiple functions that format the list using different styles or even write their own versions.
(And once (1) exists as a separate function it will also be possible to use it for other purposes. For example it could be used to retroactively add notes (git notes) to existing commits. That information could then be used to very efficiently get a list of commits that touched a certain symbol. I'll add a separate issue about that.)
The text was updated successfully, but these errors were encountered:
As mentioned in #3513 Emacs now provides diff-add-change-log-entries-other-window and we could create a Magit-specific variant of that, but considering this comment from that function I don't think it would be worth the effort just yet:
;; XXX: Currently add-change-log-entry-other-window is only called
;; once per hunk. Some hunks have multiple changes, it would be
;; good to call it for each change.
The library
add-log
, which is part of Emacs allows semi-automatically creating ChangeLog files. I think this library addresses a very real need, but does so in a highly inefficient and restrictive way.A few years back there was a period where many users requested that similar features be implemented in Magit and my position was that, this should be done by improving
add-log
and Magit would then use that improvedadd-log
. (I wasn't the only one who thought that this would be a good idea, see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16301.)Unfortunately nobody stepped up to improve that library, so I am now entertaining to do it myself or to write an alternative from scratch if I come to the conclusion that is more efficient and or that my improvements are likely to be rejected by the Emacs maintainers on grounds of them being to invasive.
Currently Magit does wrap
add-log
to provide the following commands:magit-commit-add-log
Add a stub for the current change into the commit message buffer. If no commit is in progress, then initiate it.magit-add-change-log-entry
Find change log file and add date entry and item for current change. This differs fromadd-change-log-entry
(which see) in that it acts on the current hunk in a Magit buffer instead of on a position in a file-visiting buffer.magit-add-change-log-entry-other-window
Find change log file in other window and add entry and item.I don't think the latter two commands make much sense in the age of Git. ChangeLog are now used for high-level descriptions of the changes and the extensive log can be found in the commit messages. But they will remain, just in case someone actually uses them.
But
magit-commit-add-log
isn't really all that useful either. It does not generate and insert a list of changed changes. Instead the user has to go to each change in the diff and say "and for that change too, add a stub to the commit message".The functionality should be split like so:
Currently
add-log
does not clearly separate these tasks and, if I remember correctly it doesn't do (1) at all. But that's the most essential part.Once (1) exists (in
add-log.el
or some other library), Magit will provide one function that can be added togit-commit-setup-hook
to automatically insert the list of modified symbols. Users will be able to select from multiple functions that format the list using different styles or even write their own versions.(And once (1) exists as a separate function it will also be possible to use it for other purposes. For example it could be used to retroactively add notes (
git notes
) to existing commits. That information could then be used to very efficiently get a list of commits that touched a certain symbol. I'll add a separate issue about that.)The text was updated successfully, but these errors were encountered: