8.9.1 Wip Graph

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.

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:

  *--*--*--*--*--*       refs/wip/index/refs/heads/master
 /     /     /
A-----B-----C            refs/heads/master

When magit-wip-merge-branch is nil, then creating a commit on the real branch and then making a change causes the wip refs to be recreated to fork from the new commit. But the old commits on the wip refs are not lost. They are still available from the reflog. To make it easier to see when the fork point of a wip ref was changed, an additional commit with the message "restart autosaving" is created on it (xxO commits below are such boundary commits).

Starting with

      BI0---BI1    refs/wip/index/refs/heads/master
     /
A---B              refs/heads/master
     \
      BW0---BW1    refs/wip/wtree/refs/heads/master

and committing the staged changes and editing and saving a file would result in

      BI0---BI1        refs/wip/index/refs/heads/master
     /
A---B---C              refs/heads/master
     \   \
      \   CW0---CW1    refs/wip/wtree/refs/heads/master
       \
        BW0---BW1      refs/wip/wtree/refs/heads/master@{2}

The fork-point of the index wip ref is not changed until some change is being staged. Likewise just checking out a branch or creating a commit does not change the fork-point of the working tree wip ref. The fork-points are not adjusted until there actually is a change that should be committed to the respective wip ref.