Commit 6981fc02 authored by Jonas Bernoulli's avatar Jonas Bernoulli

magit-wip-merge-branch: Change default back to nil

More work is needed before this can be enabled by default.  Merging
after committing has to be made more reliable, and log commands have
to be improved, and it must be possible to purge old wip history.
parent 085b52f6
...@@ -6327,7 +6327,7 @@ then ~HEAD~ is used in place of ~<branchref>~. ...@@ -6327,7 +6327,7 @@ then ~HEAD~ is used in place of ~<branchref>~.
Checking out another branch (or detaching ~HEAD~) causes the use of Checking out another branch (or detaching ~HEAD~) causes the use of
different wip refs for subsequent changes. different wip refs for subsequent changes.
- User Option: magit-wip-after-save-mode - User Option: magit-wip-mode
When this mode is enabled, then uncommitted changes are committed When this mode is enabled, then uncommitted changes are committed
to dedicated work-in-progress refs whenever appropriate (i.e. when to dedicated work-in-progress refs whenever appropriate (i.e. when
...@@ -6341,32 +6341,6 @@ different wip refs for subsequent changes. ...@@ -6341,32 +6341,6 @@ different wip refs for subsequent changes.
finer control over when the wip refs are updated; but that is finer control over when the wip refs are updated; but that is
discouraged. See [[*Legacy Wip Modes]]. discouraged. See [[*Legacy Wip Modes]].
- User Option: magit-wip-merge-branch
This option controls whether the current branch is merged into the
wip refs after a new commit was created on the branch.
If non-nil and the current branch has new commits, then it is
merged into the wip ref before creating a new wip commit. This
makes it easier to inspect wip history and the wip commits are
never garbage collected.
This is the default. The commit graph will look like this:
#+BEGIN_EXAMPLE
,*--*--*--*--*--* refs/wip/index/refs/heads/master
/ / /
A-----B-----C refs/heads/master
#+END_EXAMPLE
If nil and the current branch has new commits, then the wip ref
is reset to the tip of the branch before creating a new wip
commit. With this setting wip commits are eventually garbage
collected.
This used to be the default but complicates things quite a bit.
See [[*Legacy Wip Graph]] for more information.
To view the log for a branch and its wip refs use the commands To view the log for a branch and its wip refs use the commands
~magit-wip-log~ and ~magit-wip-log-current~. You should use ~--graph~ when ~magit-wip-log~ and ~magit-wip-log-current~. You should use ~--graph~ when
using these commands. using these commands.
...@@ -6430,18 +6404,38 @@ are being committed. ...@@ -6430,18 +6404,38 @@ are being committed.
Mode-line lighter for ~magit-wip--mode~. Mode-line lighter for ~magit-wip--mode~.
*** Legacy Wip Graph *** Wip Graph
The value of option ~magit-wip-merge-branch~ (which see) is ~t~ by - User Option: magit-wip-merge-branch
default. If you change it to ~nil~ (which isn't recommended) then the
following information becomes relevant. This option controls whether the current branch is merged into the
wip refs after a new commit was created on the branch.
If non-nil and the current branch has new commits, then it is
merged into the wip ref before creating a new wip commit. This
makes it easier to inspect wip history and the wip commits are
never garbage collected.
If nil and the current branch has new commits, then the wip ref
is reset to the tip of the branch before creating a new wip
commit. With this setting wip commits are eventually garbage
collected.
When ~magit-wip-merge-branch~ is ~t~, then the history looks like this:
#+BEGIN_EXAMPLE
,*--*--*--*--*--* refs/wip/index/refs/heads/master
/ / /
A-----B-----C refs/heads/master
#+END_EXAMPLE
Creating a commit and then making a change causes the wip refs to be When ~magit-wip-merge-branch~ is ~nil~, then creating a commit on the real
recreated to fork from the new commit. But the old commits on the wip branch and then making a change causes the wip refs to be recreated to
refs are not lost. They are still available from the reflog. To make fork from the new commit. But the old commits on the wip refs are not
it easier to see when the fork point of a wip ref was changed, an lost. They are still available from the reflog. To make it easier to
additional commit with the message "restart autosaving" is created on see when the fork point of a wip ref was changed, an additional commit
it (~xxO~ commits below are such boundary commits). with the message "restart autosaving" is created on it (~xxO~ commits
below are such boundary commits).
Starting with Starting with
......
...@@ -76,7 +76,7 @@ ...@@ -76,7 +76,7 @@
:group 'magit-wip-legacy :group 'magit-wip-legacy
:type 'string) :type 'string)
(defcustom magit-wip-merge-branch t (defcustom magit-wip-merge-branch nil
"Whether to merge the current branch into its wip ref. "Whether to merge the current branch into its wip ref.
If non-nil and the current branch has new commits, then it is If non-nil and the current branch has new commits, then it is
...@@ -87,7 +87,7 @@ never garbage collected. ...@@ -87,7 +87,7 @@ never garbage collected.
If nil and the current branch has new commits, then the wip ref If nil and the current branch has new commits, then the wip ref
is reset to the tip of the branch before creating a new wip is reset to the tip of the branch before creating a new wip
commit. With this setting wip commits are eventually garbage commit. With this setting wip commits are eventually garbage
collected." collected. This is currently the default."
:package-version '(magit . "2.90.0") :package-version '(magit . "2.90.0")
:group 'magit-wip :group 'magit-wip
:type 'boolean) :type 'boolean)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment