Skip to content

Commit

Permalink
faq: add an entry about why merge commits are often empty
Browse files Browse the repository at this point in the history
  • Loading branch information
martinvonz committed Nov 25, 2024
1 parent 10c90a5 commit bedd7e9
Showing 1 changed file with 18 additions and 0 deletions.
18 changes: 18 additions & 0 deletions docs/FAQ.md
Original file line number Diff line number Diff line change
Expand Up @@ -285,6 +285,24 @@ your edits, then use `jj squash` to update the earlier revision with those edits
For when you would use git stashing, use `jj edit <rev>` for expected behaviour.
Other workflows may prefer `jj edit` as well.

### Why are most merge commits marked as "(empty)"?

Jujutsu, like Git, is a snapshot-based VCS. That means that each commit
logically records the state of all current files in the repo. The changes in a
commit are not recorded but are instead calculated when needed by comparing the
commit's state to the parent commit's state. Jujutsu defines the changes in a
commit to be relative to the auto-merged parents (if there's only one parent,
then that merge is trivial - it's the parent commit's state). As a result, a
merge commit that was a clean merge (no conflict resolution, no additional
changes) is considered empty. Conversely, if the merge commit contains conflict
resolutions or additional changes, then it will be considered non-empty.

This definition of the changes in a commit is used throughout Jujutsu. It's
used by `jj diff -r` and `jj log -p` to show the changes in a commit. It's used
by `jj rebase` to rebase the changes in a commit. It's used in `jj log` to
indicate which commits are empty. It's used in the `files()` revset function
(and by `jj log <path>`) to find commits that modify a certain path. And so on.

### How do I deal with divergent changes ('??' after the [change ID])?

A [divergent change][glossary_divergent_change] represents a change that has two
Expand Down

0 comments on commit bedd7e9

Please sign in to comment.