Document 'AUTO_MERGE' and more special refs

This series adds documentation (and completion!) for AUTO_MERGE. In doing so I noticed that some other special refs where not mentioned in 'gitrevisions' nor suggested by the completion, so I also tried to improve that.

Since the changes are in the same parts of the same files, I thought it made more sense to send everything in the same series to avoid conflicts, but I can send the AUTO_MERGE patches on top of the other ones in a separate series if that would be preferred.

Here is a breakdown of the patches. First the "other special refs" patches:

* [PATCH 1/5] revisions.txt: document more special refs
* [PATCH 2/5] completion: complete REVERT_HEAD and BISECT_HEAD

Then a preparatory cleanup for the AUTO_MERGE patches:

* [PATCH 3/5] git-merge.txt: modernize word choice in "True merge" section

Finally the AUTO_MERGE patches:

* [PATCH 4/5] Documentation: document AUTO_MERGE
* [PATCH 5/5] completion: complete AUTO_MERGE

Thanks Elijah for this very useful feature! Dscho, I'm CC-ing you since you opened https://github.com/gitgitgadget/git/issues/1471, I hope that's OK.

Cheers,

Philippe.

Philippe Blain (5):
revisions.txt: document more special refs
completion: complete REVERT_HEAD and BISECT_HEAD git-merge.txt: modernize word choice in "True merge" section
Documentation: document AUTO_MERGE
completion: complete AUTO_MERGE

 Documentation/git-diff.txt             |  8 +++++++-
 Documentation/git-merge.txt            | 11 ++++++++---
 Documentation/revisions.txt            | 15 ++++++++++++--
 Documentation/user-manual.txt          | 27 ++++++++++++++++++++++++++
 contrib/completion/git-completion.bash |  2 +-
 5 files changed, 56 insertions(+), 7 deletions(-)

base-commit: a0f05f684010332ab3a706979d191b9157643f80
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1515%2Fphil-blain%2Fdoc-auto-merge-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1515/phil-blain/doc-auto-merge-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1515

gitgitgadget

From: Philippe Blain <[email protected]>

Some special refs, namely HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD, are mentioned and described in 'gitrevisions', but some others, namely REBASE_HEAD, REVERT_HEAD, and BISECT_HEAD, are not.

Add a small description of these special refs.

---
 Documentation/revisions.txt | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

index 9aa58052bc7..98b8f89bc8d 100644
@@ -32,8 +32,8 @@ characters and to avoid word splitting.
   first match in the following rules:
 
   . If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
-    useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`
-    and `CHERRY_PICK_HEAD`);
+    useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`,
+    `REBASE_HEAD`, `REVERT_HEAD`, `CHERRY_PICK_HEAD` and `BISECT_HEAD`);
 
   . otherwise, 'refs/<refname>' if it exists;
 

@@ -55,8 +55,15 @@ you can easily change the tip of the branch back to the state before you ran
 them.
 `MERGE_HEAD` records the commit(s) which you are merging into your branch
 when you run `git merge`.
+`REBASE_HEAD`, during a rebase, records the commit at which the
+operation is currently stopped, either because of conflicts or an `edit`
+command in an interactive rebase.
+`REVERT_HEAD` records the commit which you are reverting when you
+run `git revert`.
 `CHERRY_PICK_HEAD` records the commit which you are cherry-picking
 when you run `git cherry-pick`.
+`BISECT_HEAD` records the current commit to be tested when you
+run `git bisect --no-checkout`.
 +
 Note that any of the 'refs/*' cases above may come either from
 the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.

gitgitgadget

	This is usually useful only for the pseudorefs, i.e. `HEAD`,
	`FETCH_HEAD`, ..."

OK.

OK.

Looking very good.

First time I've heard that term.

Isn't HEAD supposed to be a "symbolic ref"?

It definitely seems some explanation is missing.

Felipe Contreras

In case you're looking for another option, you could convert these into a description list, which would be consistent with the outer-most list in this document.

I had to refresh myself on how the spacing and continuations work in ASCIIdoc, but I think the following (which applies on top of this patch) is right:

--- 8< ---

index 98b8f89bc8..b34f981622 100644
@@ -30,7 +30,7 @@ characters and to avoid word splitting.
   explicitly say 'heads/master' to tell Git which one you mean.
   When ambiguous, a '<refname>' is disambiguated by taking the
   first match in the following rules:
-
++
   . If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
     useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`,
     `REBASE_HEAD`, `REVERT_HEAD`, `CHERRY_PICK_HEAD` and `BISECT_HEAD`);

@@ -44,26 +44,34 @@ characters and to avoid word splitting.
   . otherwise, 'refs/remotes/<refname>' if it exists;
 
   . otherwise, 'refs/remotes/<refname>/HEAD' if it exists.
+
 +
-`HEAD` names the commit on which you based the changes in the working tree.
-`FETCH_HEAD` records the branch which you fetched from a remote repository
-with your last `git fetch` invocation.
-`ORIG_HEAD` is created by commands that move your `HEAD` in a drastic
-way (`git am`, `git merge`, `git rebase`, `git reset`),
-to record the position of the `HEAD` before their operation, so that
-you can easily change the tip of the branch back to the state before you ran
-them.
-`MERGE_HEAD` records the commit(s) which you are merging into your branch
-when you run `git merge`.
-`REBASE_HEAD`, during a rebase, records the commit at which the
-operation is currently stopped, either because of conflicts or an `edit`
-command in an interactive rebase.
-`REVERT_HEAD` records the commit which you are reverting when you
-run `git revert`.
-`CHERRY_PICK_HEAD` records the commit which you are cherry-picking
-when you run `git cherry-pick`.
-`BISECT_HEAD` records the current commit to be tested when you
-run `git bisect --no-checkout`.
+  `HEAD`:::
+    names the commit on which you based the changes in the working tree.
+  `FETCH_HEAD`:::
+    records the branch which you fetched from a remote repository with
+    your last `git fetch` invocation.
+  `ORIG_HEAD`:::
+    is created by commands that move your `HEAD` in a drastic way (`git
+    am`, `git merge`, `git rebase`, `git reset`), to record the position
+    of the `HEAD` before their operation, so that you can easily change
+    the tip of the branch back to the state before you ran them.
+  `MERGE_HEAD`:::
+    records the commit(s) which you are merging into your branch when you
+    run `git merge`.
+  `REBASE_HEAD`:::
+    during a rebase, records the commit at which the operation is
+    currently stopped, either because of conflicts or an `edit` command in
+    an interactive rebase.
+  `REVERT_HEAD`:::
+    records the commit which you are reverting when you run `git revert`.
+  `CHERRY_PICK_HEAD`:::
+    records the commit which you are cherry-picking when you run `git
+    cherry-pick`.
+  `BISECT_HEAD`:::
+    records the current commit to be tested when you run `git bisect
+    --no-checkout`.
+
 +
 Note that any of the 'refs/*' cases above may come either from
 the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.

--- >8 ---

Thanks,
Taylor

Fortunately it's easy to test:

asciidoctor - <<\EOF >foo.html
HEAD:::
names the commit on which you based the changes in the working tree.
FETCH_HEAD:::
records the branch which you fetched from a remote repository with your last git fetch invocation.
EOF

Yes, the format is fine, I'd just use :: instead of ::: as that's generally the first level, but in practical terms doesn't really matter.

https://docs.asciidoctor.org/asciidoc/latest/lists/description/

Cheers.

Felipe Contreras

From: Philippe Blain <[email protected]>

The pseudorefs REVERT_HEAD and BISECT_HEAD are not suggested by the __git_refs function. Add them there.

---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index dc95c34cc85..bcda376735c 100644
@@ -767,7 +767,7 @@ __git_refs ()
 			track=""
 			;;
 		*)
-			for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD REBASE_HEAD CHERRY_PICK_HEAD; do
+			for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD REBASE_HEAD CHERRY_PICK_HEAD REVERT_HEAD BISECT_HEAD; do
 				case "$i" in
 				$match*|$umatch*)
 					if [ -e "$dir/$i" ]; then

gitgitgadget

From: Philippe Blain <[email protected]>

The "True merge" section of the 'git merge' documentation mentions that in case of conflicts, the conflicted working tree files contain "the result of the "merge" program". This probably refers to RCS' 'merge' program, which is mentioned further down under "How conflicts are presented".

Since it is not clear at that point of the document which program is referred to, and since most modern readers probably do not relate to RCS anyway, let's just write "the merge operation" instead.

---
 Documentation/git-merge.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 0aeff572a59..23aefe28851 100644
@@ -194,7 +194,7 @@ happens:
    versions: stage 1 stores the version from the common ancestor,
    stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you
    can inspect the stages with `git ls-files -u`).  The working
-   tree files contain the result of the "merge" program; i.e. 3-way
+   tree files contain the result of the merge operation; i.e. 3-way
    merge results with familiar conflict markers `<<<` `===` `>>>`.
 5. No other changes are made.  In particular, the local
    modifications you had before you started merge will stay the

gitgitgadget

Good.

I suspect that the original refers literally to the RCS's merge program. Until caba139d (Use git-merge-file in git-merge-one-file, too, 2006-12-22) switched to use our poor-man's substitute for "merge", we used to invoke "merge" for three-way merge.

We no longer do, and a more generic "merge operation" is certainly a lot more appropriate in today's world.

From: Philippe Blain <[email protected]>

Since 5291828df8 (merge-ort: write $GIT_DIR/AUTO_MERGE whenever we hit a conflict, 2021-03-20), when using the 'ort' merge strategy, the special ref AUTO_MERGE is written when a merge operation results in conflicts. This ref points to a tree recording the conflicted state of the working tree and is very useful during conflict resolution. However, this ref is not documented.

Add some documentation for AUTO_MERGE in git-diff(1), git-merge(1), gitrevisions(7) and in the user manual.

In git-diff(1), mention it at the end of the description section, when we mention that the command also accepts trees instead of commits, and also add an invocation to the "Various ways to check your working tree" example.

In git-merge(1), add a step to the list of things that happen "when it is not obvious how to reconcile the changes", under the "True merge" secion. Also mention AUTO_MERGE in the "How to resolve conflicts" section, when mentioning 'git diff'.

In gitrevisions(7), add a mention of AUTO_MERGE along with the other special refs.

In the user manual, add a paragraph describing AUTO_MERGE to the "Getting conflict-resolution help during a merge" section, and include an example of a 'git diff AUTO_MERGE' invocation for the example conflict used in that section. Note that for uniformity we do not use backticks around AUTO_MERGE here since the rest of the document does not typeset special refs differently.

---
 Documentation/git-diff.txt    |  8 +++++++-
 Documentation/git-merge.txt   |  9 +++++++--
 Documentation/revisions.txt   |  6 +++++-
 Documentation/user-manual.txt | 27 +++++++++++++++++++++++++++
 4 files changed, 46 insertions(+), 4 deletions(-)

index 52b679256c4..a85cc756ebc 100644
@@ -102,7 +102,11 @@ If --merge-base is given, use the merge base of the two commits for the
 Just in case you are doing something exotic, it should be
 noted that all of the <commit> in the above description, except
 in the `--merge-base` case and in the last two forms that use `..`
-notations, can be any <tree>.
+notations, can be any <tree>. A tree of interest is the one pointed to
+by the special ref `AUTO_MERGE`, which is written by the 'ort' merge
+strategy upon hitting merge conflicts (see linkgit:git-merge[1]).
+Comparing the working tree with `AUTO_MERGE` shows changes you've made
+so far to resolve conflicts (see the examples below).
 
 For a more complete list of ways to spell <commit>, see
 "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].

@@ -152,6 +156,7 @@ Various ways to check your working tree::
 $ git diff            <1>
 $ git diff --cached   <2>
 $ git diff HEAD       <3>
+$ git diff AUTO_MERGE <4>
 ------------
 +
 <1> Changes in the working tree not yet staged for the next commit.

@@ -159,6 +164,7 @@ $ git diff HEAD       <3>
     would be committing if you run `git commit` without `-a` option.
 <3> Changes in the working tree since your last commit; what you
     would be committing if you run `git commit -a`
+<4> Changes in the working tree you've made to resolve conflicts so far.
 
 Comparing with arbitrary commits::
 +

index 23aefe28851..3f61389c1c2 100644
@@ -196,7 +196,11 @@ happens:
    can inspect the stages with `git ls-files -u`).  The working
    tree files contain the result of the merge operation; i.e. 3-way
    merge results with familiar conflict markers `<<<` `===` `>>>`.
-5. No other changes are made.  In particular, the local
+5. A special ref `AUTO_MERGE` is written, pointing to a tree corresponding
+   to the current content of the working tree (including conflict markers).
+   Note that this ref is only written when the 'ort' merge strategy
+   is used (the default).
+6. No other changes are made.  In particular, the local
    modifications you had before you started merge will stay the
    same and the index entries for them stay as they were,
    i.e. matching `HEAD`.

@@ -336,7 +340,8 @@ You can work through the conflict with a number of tools:
 
  * Look at the diffs.  `git diff` will show a three-way diff,
    highlighting changes from both the `HEAD` and `MERGE_HEAD`
-   versions.
+   versions. `git diff AUTO_MERGE` will show what changes you've
+   made so far to resolve conlicts.
 
  * Look at the diffs from each branch. `git log --merge -p <path>`
    will show diffs first for the `HEAD` version and then the

index 98b8f89bc8d..b42a2bb30a5 100644
@@ -33,7 +33,8 @@ characters and to avoid word splitting.
 
   . If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
     useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`,
-    `REBASE_HEAD`, `REVERT_HEAD`, `CHERRY_PICK_HEAD` and `BISECT_HEAD`);
+    `REBASE_HEAD`, `REVERT_HEAD`, `CHERRY_PICK_HEAD`, `BISECT_HEAD`
+    and `AUTO_MERGE`);
 
   . otherwise, 'refs/<refname>' if it exists;
 

@@ -64,6 +65,9 @@ run `git revert`.
 when you run `git cherry-pick`.
 `BISECT_HEAD` records the current commit to be tested when you
 run `git bisect --no-checkout`.
+`AUTO_MERGE` records a tree object corresponding to the state the
+'ort' merge strategy wrote to the working tree when a merge operation
+resulted in conflicts.
 +
 Note that any of the 'refs/*' cases above may come either from
 the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.

index dc9c6a663a9..99e5f652e92 100644
@@ -1343,6 +1343,33 @@ $ git diff -3 file.txt		# diff against stage 3
 $ git diff --theirs file.txt	# same as the above.
 -------------------------------------------------
 
+When using the 'ort' merge strategy (the default), before updating the working
+tree with the result of the merge, Git writes a special ref named AUTO_MERGE
+reflecting the state of the tree it is about to write. Conflicted paths that
+could not be automatically merged are written to this tree with conflict
+markers, just as in the working tree. AUTO_MERGE can thus be used with
+linkgit:git-diff[1] to show the changes you've made so far to resolve
+conflicts. Using the same example as above, after resolving the conflict we
+get:
+
+-------------------------------------------------
+$ git diff AUTO_MERGE
+diff --git a/file.txt b/file.txt
+index cd10406..8bf5ae7 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,5 +1 @@
+-<<<<<<< HEAD:file.txt
+-Hello world
+-=======
+-Goodbye
+->>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
++Goodbye world
+-------------------------------------------------
+
+Notice that the diff shows we deleted the conflict markers and both versions,
+and wrote "Goodbye world" instead.
+
 The linkgit:git-log[1] and linkgit:gitk[1] commands also provide special help
 for merges:
 

gitgitgadget

Neat. This does close the corresponding issue once the result gets pushed back to gitgitgadget/git. TIL!

These changes all look great to me, well written and explained.

Thanks,
Taylor

It reads correctly as-is to me. There were five lines dropped:
* Three were lines starting with '<', '=', and '>' characters,
referred to as the conflict marker lines.
* Two were lines containing content from each of the sides ("Hello
world", and "Goodbye")
and one line added.

Thus, the diff shows we deleted the conflict markers (the 1st, 3rd and 5th lines) and both versions (lines 2 and 4), and wrote "Goodbye world" instead.

Yes, upon rereading it, I can interpret it in the way it was intended. On my initial read-through, it sounded wrong. Perhaps, had it said "and both versions of the content line" or such, it wouldn't have tripped me up.

That suggestion reads well to me too.

s/secion/section/

Hi Elijah,

Le 2023-04-15 à 03:03, Elijah Newren a écrit :

Thanks for pointing out my typos, those are fixed.

That's true. I think that it might be a good idea to be explicit about "textual conflicts". Although, I think that precision should also be made in the other parts of the doc, not just the user manual, so I'll do that.

Thanks,

Philippe.

That's true. And, remerge-diff only helps when actually looking at two-way merge commit, not with conflicts hit during a rebase, cherry-pick or revert.

A semi-related trick I use to check conflict resolution during a rebase (after resolving the conflicts but before 'git rebase --continue') is to manually construct a commit from the index and use 'git range-diff' to compare it to REBASE_HEAD. Thinking out loud, maybe a '--check-resolution' flag to the sequencer would make sense to do that automatically...

<snip>

Good point. I have a small patchset to create an option allowing folks to see how conflicts were resolved in reverts, and in cherry-picks made with the -x option. I made it over two years ago, but never ended up deciding whether to submit it or not. At some point I put it up on gitgitgadget, at
https://github.com/gitgitgadget/git/pull/1151.

Points against it are that it doesn't work for rebases (because we don't know which commits they were taken from) or for many cherry-picks. Given the lower utility, and the fact that it involves commit message scraping (looking for "reverts commit <X>" and "(cherry-picked from <X>)"), I never ended up pushing for it.

Heh, I have a semi-related trick as well. During rebases, when I want to compare overall diffs for the current commit against what it was picked from, I tend to use:
mydiff <(git log -1 -p REBASE_HEAD) <(git diff HEAD)
where mydiff is a specialized wrapper around git diff --no-index that actually reads the contents of /dev/fd/<value> instead of treating it as a symlink. (Though if I don't have that script handy, I just plug in diff -u for mydiff).

From: Philippe Blain <[email protected]>

The pseudoref AUTO_MERGE is documented since the previous commit. To make it easier to use, let __git_refs in the Bash completion code complete it.

---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index bcda376735c..945d2543b07 100644
@@ -767,7 +767,7 @@ __git_refs ()
 			track=""
 			;;
 		*)
-			for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD REBASE_HEAD CHERRY_PICK_HEAD REVERT_HEAD BISECT_HEAD; do
+			for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD REBASE_HEAD CHERRY_PICK_HEAD REVERT_HEAD BISECT_HEAD AUTO_MERGE; do
 				case "$i" in
 				$match*|$umatch*)
 					if [ -e "$dir/$i" ]; then

gitgitgadget

Nice. It indeed is one of the hard-to-discover gems.

The documentation you've added is clear without being too verbose (the AUTO_MERGE description & example in patch 4 are especially helpful), the completion changes are a nice quality-of-life improvement, and the patches are well-organized. Aside from one minor (and entirely optional) suggestion in patch 1, everything in this series looks great to me. Thank you for making these changes!

Sweet, thanks for sending this in. I like the little touches you added such as 3/5,
and fixing up docs of other refs.

I found a couple typos and some slightly misleading text in 4/5.

I'm also curious if it'd be worth attempting to point out the link between AUTO_MERGE and the --remerge-diff flag to git log and git show, though even if it is, it could always be added after this series.

I wonder if it's worth mentioning that these pseudo-refs are really per-work-tree. A few too many add-ons to Git forget to take this into consideration...

Chris

Thanks everyone for the review!

Changes since v1:

* Addressed typos and wording suggestions from Elijah
* Incoporated Eric's wording suggestion
* Added a preliminary patch adressing Victoria's suggestion, based on the what Taylor sent.

This version is not a "fixups on top", it's a complete new version. I don't see the point of merging typos to master if we can instead wait for 'next' to be rebuilt after the upcoming release.

v1: This series adds documentation (and completion!) for AUTO_MERGE. In doing so I noticed that some other special refs where not mentioned in 'gitrevisions' nor suggested by the completion, so I also tried to improve that.

Since the changes are in the same parts of the same files, I thought it made more sense to send everything in the same series to avoid conflicts, but I can send the AUTO_MERGE patches on top of the other ones in a separate series if that would be preferred.

Here is a breakdown of the patches. First the "other special refs" patches:

* [PATCH 1/5] revisions.txt: document more special refs
* [PATCH 2/5] completion: complete REVERT_HEAD and BISECT_HEAD

Then a preparatory cleanup for the AUTO_MERGE patches:

* [PATCH 3/5] git-merge.txt: modernize word choice in "True merge" section

Finally the AUTO_MERGE patches:

* [PATCH 4/5] Documentation: document AUTO_MERGE
* [PATCH 5/5] completion: complete AUTO_MERGE

Thanks Elijah for this very useful feature! Dscho, I'm CC-ing you since you opened https://github.com/gitgitgadget/git/issues/1471, I hope that's OK.

Cheers,

Philippe.

Philippe Blain (6):
revisions.txt: use description list for special refs revisions.txt: document more special refs
completion: complete REVERT_HEAD and BISECT_HEAD git-merge.txt: modernize word choice in "True merge" section
Documentation: document AUTO_MERGE
completion: complete AUTO_MERGE

 Documentation/git-diff.txt             |  9 ++++-
 Documentation/git-merge.txt            | 11 ++++--
 Documentation/revisions.txt            | 50 ++++++++++++++++++--------
 Documentation/user-manual.txt          | 27 ++++++++++++++
 contrib/completion/git-completion.bash |  2 +-
 5 files changed, 79 insertions(+), 20 deletions(-)

base-commit: a0f05f684010332ab3a706979d191b9157643f80
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1515%2Fphil-blain%2Fdoc-auto-merge-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1515/phil-blain/doc-auto-merge-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1515

Range-diff vs v1:

 -:  ----------- > 1:  1bacd52a432 revisions.txt: use description list for special refs
 1:  66c7e514157 ! 2:  3e3240a78f8 revisions.txt: document more special refs

@@ Commit message
## Documentation/revisions.txt ##
@@ Documentation/revisions.txt: characters and to avoid word splitting.
first match in the following rules:
-
+ +
. If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
- useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD
- and CHERRY_PICK_HEAD);
@@ Documentation/revisions.txt: characters and to avoid word splitting.

. otherwise, 'refs/<refname>' if it exists;

-@@ Documentation/revisions.txt: you can easily change the tip of the branch back to the state before you ran
- them.
- MERGE_HEAD records the commit(s) which you are merging into your branch
- when you run git merge.
-+REBASE_HEAD, during a rebase, records the commit at which the
-+operation is currently stopped, either because of conflicts or an edit
-+command in an interactive rebase.
-+REVERT_HEAD records the commit which you are reverting when you
-+run git revert.
- CHERRY_PICK_HEAD records the commit which you are cherry-picking
- when you run git cherry-pick.
-+BISECT_HEAD records the current commit to be tested when you
-+run git bisect --no-checkout.
+@@ Documentation/revisions.txt: characters and to avoid word splitting.
+ MERGE_HEAD:::
+ records the commit(s) which you are merging into your branch when you
+ run git merge.
++ REBASE_HEAD:::
++ during a rebase, records the commit at which the operation is
++ currently stopped, either because of conflicts or an edit command in
++ an interactive rebase.
++ REVERT_HEAD:::
++ records the commit which you are reverting when you run git revert.
+ CHERRY_PICK_HEAD:::
+ records the commit which you are cherry-picking when you run `git
+ cherry-pick`.
++ BISECT_HEAD:::
++ records the current commit to be tested when you run `git bisect
++ --no-checkout`.
+
+
Note that any of the 'refs/*' cases above may come either from
- the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file.

 2:  f3a47758f9d = 3:  70487d66459 completion: complete REVERT_HEAD and BISECT_HEAD
 3:  62b68829c5a ! 4:  f1d99453f54 git-merge.txt: modernize word choice in "True merge" section

@@ Commit message

The "True merge" section of the 'git merge' documentation mentions that in case of conflicts, the conflicted working tree files contain "the
- result of the "merge" program". This probably refers to RCS' 'merge'
+ result of the "merge" program". This probably refers to RCS's 'merge'
program, which is mentioned further down under "How conflicts are presented".

4: 0cdd4ab3d73 ! 5: 612073d9508 Documentation: document AUTO_MERGE
@@ Commit message

In git-merge(1), add a step to the list of things that happen "when it is not obvious how to reconcile the changes", under the "True merge"
- secion. Also mention AUTO_MERGE in the "How to resolve conflicts"
+ section. Also mention AUTO_MERGE in the "How to resolve conflicts"
section, when mentioning 'git diff'.

In gitrevisions(7), add a mention of AUTO_MERGE along with the other
@@ Documentation/git-diff.txt: If --merge-base is given, use the merge base of the
+by the special ref AUTO_MERGE, which is written by the 'ort' merge +strategy upon hitting merge conflicts (see linkgit:git-merge[1]). +Comparing the working tree with AUTO_MERGE shows changes you've made
-+so far to resolve conflicts (see the examples below).
++so far to resolve textual conflicts (see the examples below).

For a more complete list of ways to spell <commit>, see "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
@@ Documentation/git-diff.txt: $ git diff HEAD <3>
would be committing if you run git commit without -a option.
<3> Changes in the working tree since your last commit; what you
would be committing if you run git commit -a
-+<4> Changes in the working tree you've made to resolve conflicts so far. ++<4> Changes in the working tree you've made to resolve textual
++ conflicts so far.

Comparing with arbitrary commits::
+
@@ Documentation/git-merge.txt: happens:
tree files contain the result of the merge operation; i.e. 3-way merge results with familiar conflict markers <<< === >>>.
-5. No other changes are made. In particular, the local
-+5. A special ref AUTO_MERGE is written, pointing to a tree corresponding
-+ to the current content of the working tree (including conflict markers).
-+ Note that this ref is only written when the 'ort' merge strategy
-+ is used (the default).
++5. A special ref AUTO_MERGE is written, pointing to a tree
++ corresponding to the current content of the working tree (including
++ conflict markers for textual conflicts). Note that this ref is only
++ written when the 'ort' merge strategy is used (the default).
+6. No other changes are made. In particular, the local
modifications you had before you started merge will stay the same and the index entries for them stay as they were,
@@ Documentation/git-merge.txt: You can work through the conflict with a number of
highlighting changes from both the HEAD and MERGE_HEAD
- versions.
+ versions. git diff AUTO_MERGE will show what changes you've
-+ made so far to resolve conlicts.
++ made so far to resolve textual conflicts.

* Look at the diffs from each branch. git log --merge -p <path> will show diffs first for the HEAD version and then the

## Documentation/revisions.txt ##
@@ Documentation/revisions.txt: characters and to avoid word splitting.
-
+ +
. If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD,
- REBASE_HEAD, REVERT_HEAD, CHERRY_PICK_HEAD and BISECT_HEAD);
@@ Documentation/revisions.txt: characters and to avoid word splitting.

. otherwise, 'refs/<refname>' if it exists;

-@@ Documentation/revisions.txt: run git revert.
- when you run git cherry-pick.
- BISECT_HEAD records the current commit to be tested when you
- run git bisect --no-checkout.
-+AUTO_MERGE records a tree object corresponding to the state the -+'ort' merge strategy wrote to the working tree when a merge operation -+resulted in conflicts.
+@@ Documentation/revisions.txt: characters and to avoid word splitting.
+ BISECT_HEAD:::
+ records the current commit to be tested when you run `git bisect
+ --no-checkout`.
++ AUTO_MERGE:::
++ records a tree object corresponding to the state the
++ 'ort' merge strategy wrote to the working tree when a merge operation
++ resulted in conflicts.
+
+
Note that any of the 'refs/*' cases above may come either from
- the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file.

## Documentation/user-manual.txt ##
@@ Documentation/user-manual.txt: $ git diff -3 file.txt # diff against stage 3
@@ Documentation/user-manual.txt: $ git diff -3 file.txt # diff against stage 3

+When using the 'ort' merge strategy (the default), before updating the working +tree with the result of the merge, Git writes a special ref named AUTO_MERGE
-+reflecting the state of the tree it is about to write. Conflicted paths that -+could not be automatically merged are written to this tree with conflict -+markers, just as in the working tree. AUTO_MERGE can thus be used with -+linkgit:git-diff[1] to show the changes you've made so far to resolve ++reflecting the state of the tree it is about to write. Conflicted paths with ++textual conflicts that could not be automatically merged are written to this ++tree with conflict markers, just as in the working tree. AUTO_MERGE can thus be ++used with linkgit:git-diff[1] to show the changes you've made so far to resolve
+conflicts. Using the same example as above, after resolving the conflict we +get:
+
@@ -1,5 +1 @@
++Goodbye world
+-------------------------------------------------
+
-+Notice that the diff shows we deleted the conflict markers and both versions, -+and wrote "Goodbye world" instead.
++Notice that the diff shows we deleted the conflict markers and both versions of ++the content line, and wrote "Goodbye world" instead.
+
The linkgit:git-log[1] and linkgit:gitk[1] commands also provide special help for merges:
5: 88cc7a80f31 = 6: 17226c56e7b completion: complete AUTO_MERGE

gitgitgadget

From: Philippe Blain <[email protected]>

The special refs listed in 'gitrevisions' (under the '<refname>' entry) are on separate lines in the Asciidoc source, but end up as a single continuous paragraph in the rendered documentation (see e.g. [1]). In following commits we will mention additional special refs, so to improve legibility, use a description list such that every entry appears on its own line. Since we are already in a description list, use ':::' as the term delimiter.

In order for the new description list to be aligned with the description under the '<refname>' entry, instead of being aligned with the last entry of the "in the following rules" nested list, use the "ancestor list continuation" syntax [2], i.e., leave an empty line before the continuation '+'. Do the same for the paragraph following the new description list ("Note that any...").

While at it, also use a continuation '+' before the "in the following rules" list, for correctness. The parser seems not to care here, but it's best to keep the sources correct.

[1] https://git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-emltrefnamegtemegemmasterememheadsmasterememrefsheadsmasterem
[2] https://docs.asciidoctor.org/asciidoc/latest/lists/continuation/#ancestor-list-continuation

---
 Documentation/revisions.txt | 32 +++++++++++++++++++-------------
 1 file changed, 19 insertions(+), 13 deletions(-)

index 9aa58052bc7..ab5b8cf880b 100644
@@ -30,7 +30,7 @@ characters and to avoid word splitting.
   explicitly say 'heads/master' to tell Git which one you mean.
   When ambiguous, a '<refname>' is disambiguated by taking the
   first match in the following rules:
-
++
   . If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
     useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`
     and `CHERRY_PICK_HEAD`);

@@ -44,19 +44,25 @@ characters and to avoid word splitting.
   . otherwise, 'refs/remotes/<refname>' if it exists;
 
   . otherwise, 'refs/remotes/<refname>/HEAD' if it exists.
+
 +
-`HEAD` names the commit on which you based the changes in the working tree.
-`FETCH_HEAD` records the branch which you fetched from a remote repository
-with your last `git fetch` invocation.
-`ORIG_HEAD` is created by commands that move your `HEAD` in a drastic
-way (`git am`, `git merge`, `git rebase`, `git reset`),
-to record the position of the `HEAD` before their operation, so that
-you can easily change the tip of the branch back to the state before you ran
-them.
-`MERGE_HEAD` records the commit(s) which you are merging into your branch
-when you run `git merge`.
-`CHERRY_PICK_HEAD` records the commit which you are cherry-picking
-when you run `git cherry-pick`.
+  `HEAD`:::
+    names the commit on which you based the changes in the working tree.
+  `FETCH_HEAD`:::
+    records the branch which you fetched from a remote repository with
+    your last `git fetch` invocation.
+  `ORIG_HEAD`:::
+    is created by commands that move your `HEAD` in a drastic way (`git
+    am`, `git merge`, `git rebase`, `git reset`), to record the position
+    of the `HEAD` before their operation, so that you can easily change
+    the tip of the branch back to the state before you ran them.
+  `MERGE_HEAD`:::
+    records the commit(s) which you are merging into your branch when you
+    run `git merge`.
+  `CHERRY_PICK_HEAD`:::
+    records the commit which you are cherry-picking when you run `git
+    cherry-pick`.
+
 +
 Note that any of the 'refs/*' cases above may come either from
 the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.

gitgitgadget

From: Philippe Blain <[email protected]>

Some special refs, namely HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD, are mentioned and described in 'gitrevisions', but some others, namely REBASE_HEAD, REVERT_HEAD, and BISECT_HEAD, are not.

Add a small description of these special refs.

---
 Documentation/revisions.txt | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

index ab5b8cf880b..b34f981622b 100644
@@ -32,8 +32,8 @@ characters and to avoid word splitting.
   first match in the following rules:
 +
   . If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
-    useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`
-    and `CHERRY_PICK_HEAD`);
+    useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`,
+    `REBASE_HEAD`, `REVERT_HEAD`, `CHERRY_PICK_HEAD` and `BISECT_HEAD`);
 
   . otherwise, 'refs/<refname>' if it exists;
 

@@ -59,9 +59,18 @@ characters and to avoid word splitting.
   `MERGE_HEAD`:::
     records the commit(s) which you are merging into your branch when you
     run `git merge`.
+  `REBASE_HEAD`:::
+    during a rebase, records the commit at which the operation is
+    currently stopped, either because of conflicts or an `edit` command in
+    an interactive rebase.
+  `REVERT_HEAD`:::
+    records the commit which you are reverting when you run `git revert`.
   `CHERRY_PICK_HEAD`:::
     records the commit which you are cherry-picking when you run `git
     cherry-pick`.
+  `BISECT_HEAD`:::
+    records the current commit to be tested when you run `git bisect
+    --no-checkout`.
 
 +
 Note that any of the 'refs/*' cases above may come either from

gitgitgadget

From: Philippe Blain <[email protected]>

The pseudorefs REVERT_HEAD and BISECT_HEAD are not suggested by the __git_refs function. Add them there.

---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index dc95c34cc85..bcda376735c 100644
@@ -767,7 +767,7 @@ __git_refs ()
 			track=""
 			;;
 		*)
-			for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD REBASE_HEAD CHERRY_PICK_HEAD; do
+			for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD REBASE_HEAD CHERRY_PICK_HEAD REVERT_HEAD BISECT_HEAD; do
 				case "$i" in
 				$match*|$umatch*)
 					if [ -e "$dir/$i" ]; then

gitgitgadget

From: Philippe Blain <[email protected]>

The "True merge" section of the 'git merge' documentation mentions that in case of conflicts, the conflicted working tree files contain "the result of the "merge" program". This probably refers to RCS's 'merge' program, which is mentioned further down under "How conflicts are presented".

Since it is not clear at that point of the document which program is referred to, and since most modern readers probably do not relate to RCS anyway, let's just write "the merge operation" instead.

---
 Documentation/git-merge.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 0aeff572a59..23aefe28851 100644
@@ -194,7 +194,7 @@ happens:
    versions: stage 1 stores the version from the common ancestor,
    stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you
    can inspect the stages with `git ls-files -u`).  The working
-   tree files contain the result of the "merge" program; i.e. 3-way
+   tree files contain the result of the merge operation; i.e. 3-way
    merge results with familiar conflict markers `<<<` `===` `>>>`.
 5. No other changes are made.  In particular, the local
    modifications you had before you started merge will stay the

gitgitgadget

From: Philippe Blain <[email protected]>

Since 5291828df8 (merge-ort: write $GIT_DIR/AUTO_MERGE whenever we hit a conflict, 2021-03-20), when using the 'ort' merge strategy, the special ref AUTO_MERGE is written when a merge operation results in conflicts. This ref points to a tree recording the conflicted state of the working tree and is very useful during conflict resolution. However, this ref is not documented.

Add some documentation for AUTO_MERGE in git-diff(1), git-merge(1), gitrevisions(7) and in the user manual.

In git-diff(1), mention it at the end of the description section, when we mention that the command also accepts trees instead of commits, and also add an invocation to the "Various ways to check your working tree" example.

In git-merge(1), add a step to the list of things that happen "when it is not obvious how to reconcile the changes", under the "True merge" section. Also mention AUTO_MERGE in the "How to resolve conflicts" section, when mentioning 'git diff'.

In gitrevisions(7), add a mention of AUTO_MERGE along with the other special refs.

In the user manual, add a paragraph describing AUTO_MERGE to the "Getting conflict-resolution help during a merge" section, and include an example of a 'git diff AUTO_MERGE' invocation for the example conflict used in that section. Note that for uniformity we do not use backticks around AUTO_MERGE here since the rest of the document does not typeset special refs differently.

---
 Documentation/git-diff.txt    |  9 ++++++++-
 Documentation/git-merge.txt   |  9 +++++++--
 Documentation/revisions.txt   |  7 ++++++-
 Documentation/user-manual.txt | 27 +++++++++++++++++++++++++++
 4 files changed, 48 insertions(+), 4 deletions(-)

index 52b679256c4..08087ffad5f 100644
@@ -102,7 +102,11 @@ If --merge-base is given, use the merge base of the two commits for the
 Just in case you are doing something exotic, it should be
 noted that all of the <commit> in the above description, except
 in the `--merge-base` case and in the last two forms that use `..`
-notations, can be any <tree>.
+notations, can be any <tree>. A tree of interest is the one pointed to
+by the special ref `AUTO_MERGE`, which is written by the 'ort' merge
+strategy upon hitting merge conflicts (see linkgit:git-merge[1]).
+Comparing the working tree with `AUTO_MERGE` shows changes you've made
+so far to resolve textual conflicts (see the examples below).
 
 For a more complete list of ways to spell <commit>, see
 "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].

@@ -152,6 +156,7 @@ Various ways to check your working tree::
 $ git diff            <1>
 $ git diff --cached   <2>
 $ git diff HEAD       <3>
+$ git diff AUTO_MERGE <4>
 ------------
 +
 <1> Changes in the working tree not yet staged for the next commit.

@@ -159,6 +164,8 @@ $ git diff HEAD       <3>
     would be committing if you run `git commit` without `-a` option.
 <3> Changes in the working tree since your last commit; what you
     would be committing if you run `git commit -a`
+<4> Changes in the working tree you've made to resolve textual
+    conflicts so far.
 
 Comparing with arbitrary commits::
 +

index 23aefe28851..8625c5cb0ec 100644
@@ -196,7 +196,11 @@ happens:
    can inspect the stages with `git ls-files -u`).  The working
    tree files contain the result of the merge operation; i.e. 3-way
    merge results with familiar conflict markers `<<<` `===` `>>>`.
-5. No other changes are made.  In particular, the local
+5. A special ref `AUTO_MERGE` is written, pointing to a tree
+   corresponding to the current content of the working tree (including
+   conflict markers for textual conflicts).  Note that this ref is only
+   written when the 'ort' merge strategy is used (the default).
+6. No other changes are made.  In particular, the local
    modifications you had before you started merge will stay the
    same and the index entries for them stay as they were,
    i.e. matching `HEAD`.

@@ -336,7 +340,8 @@ You can work through the conflict with a number of tools:
 
  * Look at the diffs.  `git diff` will show a three-way diff,
    highlighting changes from both the `HEAD` and `MERGE_HEAD`
-   versions.
+   versions. `git diff AUTO_MERGE` will show what changes you've
+   made so far to resolve textual conflicts.
 
  * Look at the diffs from each branch. `git log --merge -p <path>`
    will show diffs first for the `HEAD` version and then the

index b34f981622b..6ea6c7cead1 100644
@@ -33,7 +33,8 @@ characters and to avoid word splitting.
 +
   . If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
     useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`,
-    `REBASE_HEAD`, `REVERT_HEAD`, `CHERRY_PICK_HEAD` and `BISECT_HEAD`);
+    `REBASE_HEAD`, `REVERT_HEAD`, `CHERRY_PICK_HEAD`, `BISECT_HEAD`
+    and `AUTO_MERGE`);
 
   . otherwise, 'refs/<refname>' if it exists;
 

@@ -71,6 +72,10 @@ characters and to avoid word splitting.
   `BISECT_HEAD`:::
     records the current commit to be tested when you run `git bisect
     --no-checkout`.
+  `AUTO_MERGE`:::
+    records a tree object corresponding to the state the
+    'ort' merge strategy wrote to the working tree when a merge operation
+    resulted in conflicts.
 
 +
 Note that any of the 'refs/*' cases above may come either from

index dc9c6a663a9..aa385137adc 100644
@@ -1343,6 +1343,33 @@ $ git diff -3 file.txt		# diff against stage 3
 $ git diff --theirs file.txt	# same as the above.
 -------------------------------------------------
 
+When using the 'ort' merge strategy (the default), before updating the working
+tree with the result of the merge, Git writes a special ref named AUTO_MERGE
+reflecting the state of the tree it is about to write. Conflicted paths with
+textual conflicts that could not be automatically merged are written to this
+tree with conflict markers, just as in the working tree. AUTO_MERGE can thus be
+used with linkgit:git-diff[1] to show the changes you've made so far to resolve
+conflicts. Using the same example as above, after resolving the conflict we
+get:
+
+-------------------------------------------------
+$ git diff AUTO_MERGE
+diff --git a/file.txt b/file.txt
+index cd10406..8bf5ae7 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,5 +1 @@
+-<<<<<<< HEAD:file.txt
+-Hello world
+-=======
+-Goodbye
+->>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
++Goodbye world
+-------------------------------------------------
+
+Notice that the diff shows we deleted the conflict markers and both versions of
+the content line, and wrote "Goodbye world" instead.
+
 The linkgit:git-log[1] and linkgit:gitk[1] commands also provide special help
 for merges:
 

gitgitgadget

From: Philippe Blain <[email protected]>

The pseudoref AUTO_MERGE is documented since the previous commit. To make it easier to use, let __git_refs in the Bash completion code complete it.

---
 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index bcda376735c..945d2543b07 100644
@@ -767,7 +767,7 @@ __git_refs ()
 			track=""
 			;;
 		*)
-			for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD REBASE_HEAD CHERRY_PICK_HEAD REVERT_HEAD BISECT_HEAD; do
+			for i in HEAD FETCH_HEAD ORIG_HEAD MERGE_HEAD REBASE_HEAD CHERRY_PICK_HEAD REVERT_HEAD BISECT_HEAD AUTO_MERGE; do
 				case "$i" in
 				$match*|$umatch*)
 					if [ -e "$dir/$i" ]; then

gitgitgadget

I re-read the whole series. It addresses all the things I brought up in v1 (except the bonus idea I threw out there about mentioning how AUTO_MERGE is related to --remerge-diff), and all the things I remember others bringing up as well.

Thanks for working on this!

Thanks.

The previous one I'd discard and replace with this one when opening the tree for the next cycle.

OK. Let's eject what is in 'next' then.