docs: correct mistakes in git-merge
PATCH 1/1 docs: correct mistakes in git-merge
From: Timur Sultanaev <[email protected]>
Documentation for git-merge incorrectly notes that tip of the current branch on ascii diagram is C , while it is actually G (current branch is master, HEAD on diagram is G).
Additionally diagrams on the page are adjusted to use spaces instead of tabs, so that they align regardless of tab size. This is in line with diagrams on other git documentation pages.
---
Correct mistakes in git-merge documentation
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1940%2Fstrowk%2Fmaster-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1940/strowk/master-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1940
Documentation/git-merge.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
Documentation/git-merge.adoc +5 -5
@@ -28,8 +28,8 @@ Assume the following history exists and the current branch is `master`: ------------ - A---B---C topic - / + A---B---C topic + / D---E---F---G master ------------
@@ -38,11 +38,11 @@ Then `git merge topic` will replay the changes made on the its current commit (`C`) on top of `master`, and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes. Before the operation, -`ORIG_HEAD` is set to the tip of the current branch (`C`). +`ORIG_HEAD` is set to the tip of the current branch (`G`). ------------ - A---B---C topic - / \ + A---B---C topic + / \ D---E---F---G---H master ------------
base-commit: 8b6f19ccfc3aefbd0f22f6b7d56ad6a3fc5e4f37
Signature · 1 line
gitgitgadget
Hi Tumur,
Quoted 11 lines · Timur Sultanaev via GitGitGadget
From: Timur Sultanaev <[email protected]>
Documentation for git-merge incorrectly notes that tip of the current branch on ascii diagram is C , while it is actually G (current branch is master, HEAD on diagram is G).
Additionally diagrams on the page are adjusted to use spaces instead of tabs, so that they align regardless of tab size. This is in line with diagrams on other git documentation pages.
To be precise, you could add to the commit message that the faulty description was introduced in 0c514d576685 (git-merge.txt: mention 'ORIG_HEAD' in the Description, 2023-01-10). (I Cc:ed Philippe Blain who authored that patch.)
Quoted 16 lines
Signed-off-by Timur Sultanaev <[email protected]>---
Correct mistakes in git-merge documentationPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1940%2Fstrowk%2Fmaster-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1940/strowk/master-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1940Documentation/git-merge.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)Documentation/git-merge.adoc +0
-0
Documentation/git-merge.adoc Assume the following history exists and the current branch is · line 32
Quoted 7 lines
Documentation/git-merge.adoc +2
-2@@ -28,8 +28,8 @@ Assume the following history exists and the current branch is `master`: ------------ - A---B---C topic - / + A---B---C topic + /
This replaces tabs with spaces — though elsewhere in the file, tabs continue to roam free. The change assumes your pager or editor shares Git’s long-standing view that tabs are 8 columns wide (a convention with many loyal followers, even if not universally embraced...). That said, while correcting the description seemed fairly straight-forward, this white-space change appears to tread on more delicate territory. It might deserve its own patch — though I wouldn’t be shocked if it quietly joins the fate of the dodo.
The same applies to the white-space change at the end of this patch.
Documentation/git-merge.adoc Then `git merge topic` will replay the changes made on the · line 41
Quoted 9 lines
Documentation/git-merge.adoc +1
-1D---E---F---G master ------------@@ -38,11 +38,11 @@ Then `git merge topic` will replay the changes made on the its current commit (`C`) on top of `master`, and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes. Before the operation, -`ORIG_HEAD` is set to the tip of the current branch (`C`). +`ORIG_HEAD` is set to the tip of the current branch (`G`).
This is obviously a good fix.
Ciao,
Johannes
Quoted 15 lines
Documentation/git-merge.adoc +2
-2------------ - A---B---C topic - / \ + A---B---C topic + / \ D---E---F---G---H master ------------base-commit:
8b6f19ccfc3aefbd0f22f6b7d56ad6a3fc5e4f37Signature · 1 line
gitgitgadget
Quoted 20 lines · Johannes Schindelin
Quoted 4 lines
Additionally diagrams on the page are adjusted to use spaces instead of tabs, so that they align regardless of tab size. This is in line with diagrams on other git documentation pages.
To be precise, you could add to the commit message that the faulty description was introduced in
0c514d576685(git-merge.txt: mention 'ORIG_HEAD' in the Description, 2023-01-10). (I Cc:ed Philippe Blain who authored that patch.)
...Documentation/git-merge.adoc Assume the following history exists and the current branch is · line 32
Quoted 5 lines
------------
Documentation/git-merge.adoc +2
-2- A---B---C topic - / + A---B---C topic + /... while correcting the description seemed fairly straight-forward, this white-space change appears to tread on more delicate territory. It might deserve its own patch
...
Quoted 8 lines
Documentation/git-merge.adoc Then `git merge topic` will replay the changes made on the · line 41
Quoted 6 lines
Documentation/git-merge.adoc +1
-1@@ -38,11 +38,11 @@ Then `git merge topic` will replay the changes made on the its current commit (`C`) on top of `master`, and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes. Before the operation, -`ORIG_HEAD` is set to the tip of the current branch (`C`). +`ORIG_HEAD` is set to the tip of the current branch (`G`).This is obviously a good fix.
All comments are good ones for contributors to keep in mind for their next attempt.
For this particular one, which is already in 'master', there is no point in polishing and resending the patch, though ;-)
Thanks.