From 8c4e09dff83847ac7f07bf1da7751e9328006c4d Mon Sep 17 00:00:00 2001 From: Jack Jamison Date: Thu, 30 Jul 2026 20:09:00 -0400 Subject: actual final changes and get rid of junk in lisp dir actually works fine --- .config/emacs/lisp/magit/docs/RelNotes/2.1.0.txt | 433 ----------------------- 1 file changed, 433 deletions(-) delete mode 100644 .config/emacs/lisp/magit/docs/RelNotes/2.1.0.txt (limited to '.config/emacs/lisp/magit/docs/RelNotes/2.1.0.txt') diff --git a/.config/emacs/lisp/magit/docs/RelNotes/2.1.0.txt b/.config/emacs/lisp/magit/docs/RelNotes/2.1.0.txt deleted file mode 100644 index 85e8d41..0000000 --- a/.config/emacs/lisp/magit/docs/RelNotes/2.1.0.txt +++ /dev/null @@ -1,433 +0,0 @@ -Magit v2.1.0 Release Notes -========================== - -Released 1 July 2015 by Jonas Bernoulli. - -This release marks the end of a commit marathon that lasted for more -than 4700 commits. It is the first major release in over two and a -half years. The last major release was 1.2.0, which was released -under old leadership. Version 1.4.0, which I released earlier this -year, for the most part consisted of changes that prepared for this -release (so you might want to read the respective release notes too). - -This release comes with many new and exciting features, but the most -important change is the massive increase in consistency both in the -user interface and the internal abstractions. - -Magit always provided a very intuitive staging interface, which is -vastly superior to `git add --interactive'. This release extends this -to other apply variants. Starting with this release, other areas have -also begun to be more than just incremental improvements over what Git -itself provides. But this is still limited to certain features which -have gotten more attention than others (most prominently rebasing). - -Interlude ---------- - -The code base is finally in a state that allows me to concentrate on -implementing my vision of what version control could be like. But -this will only be possible if, unlike during the last two and a half -years, I am being paid for my work. - -I intend to run a fund-raising campaign, but you can already donate -now (see http://magit.vc/donations.html). I am also looking for -corporate sponsorship and/or employment. One area where Magit -actually lags behind other Git clients is integration with Git hosting -platforms and code review tools. I hope that these platforms have an -interest in being supported by the best Git client and are willing to -pay for it. - -I am very interested in a job that would let me work on Magit *and* on -other projects, which would benefit from the skills I have acquired -integrating two complex systems and dealing with all the social and -technical challenges that arise when running a popular project. - -Changes since v1.4.0 --------------------- - - * A new manual has been added. It's much more comprehensive than the - old manual and instead of just documenting the various commands and - options, it also explains concepts and plumbing functions, and - comes with extensive indices for commands, functions, and options. - - Actually three new manuals were added; the packages `magit-popup' - and `with-editor' are documented in separate manuals. - - The manuals are written in Org mode and then exported to Texinfo. - - * Performance is much better now. In most cases this was achieved by - delaying work until it is actually needed. Most importantly diffs - are only partially washed until being fully expanded. Some - features come in a fancy and in a fast variant; when that is the - case, we now usually default to the fast variant. - - * Many options can now be set on a per-repository basis, and the - manual describes how to do so. (Actually this was always possible - but, because it was undocumented, nobody did it.) It's possible to - define "repository classes", e.g. "huge repositories", and then add - the respective repositories to that class. This is very useful in - order to turn off certain features only in repositories where they - would have a negative impact on performance, without having to do - it for each repository individually. - - * Many faces have been simplified. Most importantly, section heading - faces no longer set a background color (except for hunk headings) - and instead just use the default background. Refname faces no - longer set the background color or the box property. - - * Many, probably the majority of, functions, variables, and faces - have been renamed, which was necessary because there was very - little consistency before. - - Most importantly, the names of commands and options now begin with - a prefix that includes the name of the respective git sub-command. - For example, the names of all commands and options related to - diffing now begin with `magit-diff-'. - - Many plumbing functions and variables were also renamed. In some - cases, that also lead to shared prefixes, such as `magit-process-', - `magit-mode-', `magit-git-', and `magit-insert-'. But many - plumbing functions and variables continue to use names whose only - common part is the `magit-' prefix. - - Future renames will be performed at well defined times and obsolete - function/variable definitions will be provided for backward - compatibility. No renames are planned at present. - - * The external libraries `git-commit-mode.el' and `git-rebase-mode.el' - are no longer required and have to be uninstalled because they - conflict with their successors `git-commit.el' and `git-rebase.el', - which are now maintained inside the Magit repository instead of the - Git-Modes repository. - - The library `git-commit.el' can be used without Magit, so it is - distributed as a separate Elpa package. However, `git-rebase.el' - now depends on several Magit libraries and is therefore distributed - as part of the `magit' package. - - * The library `magit-key-mode.el' was removed and replaced with - `magit-popup.el'. The new implementation is much more flexible and - easier to use than the old one. Major new features include setting - default arguments directly inside the popup and macros for defining - new popups and extending existing popups. - - This new library can also be used by packages that are not related - to Magit and is therefore available as a separate Elpa package. - - * The library `with-editor.el' was added. Its purpose is to use the - emacsclient as $GIT_EDITOR when git is started as a subprocess and - requires an editor. This is used while committing and rebasing. - This also works over Tramp, where a "sleeping editor" shell script - is used to communicate over standard output instead of a socket - like the emacsclient does. - - The `1.4.0' release already supported this, but this release splits - this feature into a separate library. And now that it is a separate - library, it can also be used by packages that are not related to - Magit. `with-editor.el' is distributed as a separate Elpa package. - - * All libraries are now located in the new `lisp/' subdirectory. - - * The library `magit.el' has been split into many new libraries. - The code base is now much better organized. Together with the - description of plumbing commands in the manual, this should make it - much easier for contributors to get started. - - * The library `magit-wip.el' has been rewritten from scratch and no - longer depends on the external and unmaintained shell script from - https://github.com/bartman/git-wip. - - * There are now three different modes that commit to the - work-in-progress refs before/after certain events, and in addition - to the old working tree wip refs, these modes now also commit to - index wip refs. When these new modes are turned on, Git's - protection of committed (but dangling) changes is effectively - extended to uncommitted changes (which some exceptions). These - modes are not enabled by default due to performance concerns. - - * The library `magit-blame.el' has been rewritten from scratch. The - new implementation can blame recursively, jump to the next/previous - chunk from the same commit, replace headings with separator lines, - scroll the revision buffer for the chunk at point (like log buffers), - and fine-tune the arguments for `git blame' using a popup. - - * The new library `magit-ediff.el' replaces the old Ediff support. - The new implementation comes with a dwim command and a popup, and - it relies less on high-level functions provided by VC and Ediff - itself, because many of those turned out to be unsuitable. - - * The popular third-party library `dash.el' is now required. This - is the only mandatory external dependency now, except for Git and - Emacs themselves, of course. - - * When using Ido inside Magit, users now have to install the - third-party library `ido-completing-read+.el'. This is necessary - because the function `ido-completing-read', which is part of the - built-in library `ido.el', is not a sufficient drop-in replacement - for `completing-read'. - - * The new macro `magit-insert-section' replaces `magit-with-section'. - The macros `magit-cmd-insert-section' and `magit-git-insert-section' - were removed without a direct replacement. - - * The new functions `magit-insert' and `magit-put-face-property' take - care of working around the fact that negative overlay priorities - are not supported, i.e., that overlays always take precedence - against text properties. Previously this was done in various - places, and not always correctly (e.g., in some cases overlays did - not evaporate). - - * The section visibility and movement commands were rewritten from - scratch. All those commands now share the prefix `magit-section-' - and edge cases are handled better. New commands were added that - allow cycling the visibility of sections and their children. From - a user perspective Magit's section handling is now quite similar to - that of Org mode. - - * The macro `magit-section-action' was removed. The related macro - `magit-section-case' still exists and will continue to do so. The - action variant provided user-customizable hooks, but these hooks - were rarely, if ever, used. Instead of such action hooks, users who - wish to extend Magit now have to use type-specific section keymaps. - - * Section highlighting was rewritten from scratch. The new - implementation uses hooks to allow washing certain section types - differently than others - without obfuscating the simple cases. - Washing diffs is much more complicated than washing all other - sections, and that part has been factored out. The washing of - all other section types is now quite simple. - - * The appearance of the region now indicates whether it is valid as a - selection. As far as Magit is concerned, valid selections are hunk - internal regions and regions that mark sibling sections of the same - type. When a region does not satisfy one of these, then it is - displayed the sames as in other buffers and Magit cannot act on it. - - * The new option `magit-no-confirm' makes it easy to forgo having to - confirm potentially dangerous actions. Many of these actions are - only dangerous for users who don't know how to undo them. When the - wip modes are turned on, many more previously fatal actions can be - easily undone. Adding `safe-with-wip' here makes it unnecessary to - confirm these actions. - - * The new Refs buffer combines the features of the old Wazzup and - Branch Manager buffers into one, more powerful and efficient - synthesis. For each reference, cherries can be shown by expanding - the ref section, but unlike in the Wazzup buffer, the cherries are - not calculated until the expansion happens, making it vastly more - efficient. Besides local and remote branches, the buffer now also - lists tags, and users can add additional sections listing other - refs, e.g., stashes. The format of refs headers is now - customizable. - - * File-visiting buffers are now reverted without using code from the - built-in `autorevert.el` library. The function we previously used - was intended for internal use only and indeed, changes made there - broke Magit in the past. - - * The new option `magit-revert-buffers' controls whether and how - buffers visiting tracked files are reverted. As before, such - buffers are reverted by default. But by default this is now done - rather noisily to encourage users to read the doc-string and - pick what is right for them. It's now also possible to revert - asynchronously and for the user to be asked every time there are - buffers that could be reverted. This option replaces - `magit-auto-revert-mode`. - - * Many new section inserters are available. Some are variations of - default inserters; `magit-insert-unpulled-cherries', for example, is - like `magit-insert-unpulled-commits' but prefixes each commit with - "+" or "-" to indicate its "cherry state". Other inserters are - completely new (e.g., `magit-insert-unpulled-module-commits'). - - * The header sections in status buffers can now be customized using - the new `magit-status-headers-hook'. This is an additional section - insertion hook; separating it from `magit-status-sections-hook' - gives users complete control over what information is displayed in - the headers, while still making the first header the parent section - of all the other header lines. - - * Many commands that previously could only act on the section at - point can now act on all sections selected by a region, which can - span sibling sections of the same type. - - * Many commands now more intelligently dwim based on the section at - point. - - * Where it makes sense, completion and confirmation have been merged - into a single user action. Many commands that previously allowed - carrying out or aborting some action now also allow the user to act - on something different from the default choice. Where one - previously had to confirm with `yes RET', one now confirms with just - `RET' (to accept the default choice, which previously was the only - choice). - - * The distinction between the various "apply variants" has been - clearly worked out, and they now all provide the same feature set. - The variants are: stage, unstage, discard, reverse, and "regular - apply". In all cases, it is possible to act on a file or hunk, or - part of a hunk. When acting on the hunk level, all variants are - implemented on top of `git apply', thus the name "apply variants". - - Un-/staging has always been one of Magit's most beloved features, - and this release takes it to the next level by making the other - apply variants just as consistent, powerful, and intuitive to use. - - All apply variants are context aware, meaning that, for example, the - stage variant knows that an already staged change cannot be staged. - That leads to better error messages. - - * The committing prefix now features additional variants. It was - already possible to quickly create a fixup or squash commit; the - new variants do that and then also instantly perform a rebase to - actually combine these commits with their intended target commits. - - * Rebase sequences are now initiated from the new rebasing prefix. - Several rebasing variants exist, of course including basic - "rebase onto something" and interactive rebase. Other variants - automatically detect and combine squash and fixup commits with - their intended targets. Others let the user edit or reword a - single commit, without having to go through the steps that are - irrelevant in these cases. - - * When a rebase sequence stops at a commit, then the rebasing prefix - instead features suffix commands for continuing, editing, or - aborting the sequence; or skipping the current commit. - - * When a rebase sequence stops, the status buffer displays a list of - the already applied and yet-to-be applied commits. These commits - can be acted on like those in logs. - - * Cherry-picking, reverting, and applying patches using `git am' are - treated the same way as rebasing. A prefix command features - several variants to initiate the sequence. When a sequence is in - progress, then the same prefix instead features suffix commands for - continuing or aborting the sequence, and the status buffer lists - the relevant commits. - - * The magit-specific "rewriting" feature has been removed because it - was a hybrid of "rebasing" and "cherry-picking" and vastly - inferior to both of them. - - * The merging prefix features several new convenient merge variants. - - * Merges can now be previewed before actually carrying them out. - - * When a merge results in conflicts then the commits being merged are - listed in the status buffer, making it easier to review conflicting - changes in the context they were created. - - * Its now possible to discard one side of a conflict directly from - the hunk containing the conflict, using the regular discard key - `k'. It's also possible to restore a conflict. - - * When using an existing branch as the starting-point of a new - branch, it is now automatically configured as the upstream branch. - - * The branching prefix now features suffix commands for un-/setting - the upstream branch. Previously this was coupled with pushing in - a truly obscure way. - - * Branch descriptions can now be displayed in the refs or status - buffer, and the description can be edited using a suffix command - from the branching prefix. - - * The URL of a remote can now be changed from the remoting prefix. - - * A new pulling prefix command was added, which features several new - pulling variants. Previously only one pulling command existed and - it had to be controlled using prefix arguments, which was very - cumbersome. - - * A new pushing prefix command was added, which features several new - pushing variants. Previously only one pushing command existed and - it had to be controlled using prefix arguments, which was very - cumbersome. - - * The various tagging commands are now suffix commands of the new - tagging prefix command. - - * It is now possible to stash, or create a snapshot from, just the - staged or the unstaged changes, instead of both. Suffix commands - for branching, listing, and showing stashes were added to the - stashing prefix - - * When creating stashes the new implementation in `magit-wip.el' is - used instead of `git stash'. This allows the user to create - snapshot stashes without touching any files in the working tree. - - * The submodule prefix now features new suffix commands for adding, - setting up, and fetching modules. - - * Submodules with unmerged commits can now be displayed in the status - buffer. Sections representing submodules can be expanded to show - their unpulled commits. These commits can be acted on like commits - belonging to the super-project. - - * Support for displaying diffs inside the log buffer instead of in a - separate diff buffer has been removed. It might come back one day, - but the old implementation had just fallen behind regular one-line - log too much. - - * The logging prefix features many new infix arguments and suffix - commands, which can now be combined in more flexible ways than - before. - - * Many commands that previously read a single commit, branch, or - file in the minibuffer, can now read multiple, comma-separated items - from the user, while providing completion candidates for all of - them. Likewise, when selecting a range, completion is available - for the second commit too. - - * All of Git's reset variants are now exposed as individual commands, - but not all of them have a key binding by default. - -This was just the tip of the iceberg. - -Authors -------- - - 2187 Jonas Bernoulli - 28 Sebastian Wiesner - 25 Kyle Meyer - 19 Noam Postavsky - 17 Pieter Praet - 12 Rémi Vanicat - 9 Florian Ragwitz - 5 Philippe Vaucher - 5 Ramkumar Ramachandra - 4 Cornelius Mika - 4 Kan-Ru Chen - 4 Syohei Yoshida - 3 Alex Dunn - 3 Alex Kost - 3 Nicolas Richard - 2 Eric Schulte - 2 Ingo Lohmar - 2 Mitchel Humpherys - 2 Peter Eisentraut - 2 Ryan C. Thompson - 1 Adeodato Simó - 1 Andrew Schwartzmeyer - 1 Andy Sawyer - 1 Bradley Wright - 1 Guillaume Martres - 1 John Mastro - 1 John Wiegley - 1 Julien Danjou - 1 Lingchao Xin - 1 Mark Oteiza - 1 Michael Fogleman - 1 Michael Griffiths - 1 Michal Sojka - 1 Natalie Weizenbaum - 1 Oleh Krehel - 1 Peter Vasil - 1 Rüdiger Sonderfeld - 1 Steven E. Harris - 1 Teemu Likonen - 1 Thomas A Caswell - 1 Tim Perkins - 1 Tim Wraight - 1 Wei Huang - 1 Xavier Noria -- cgit v1.2.3