Re: [PATCH v3 7/7] rebase: fix formatting of rebase --reapply-cherry-picks option in docs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Elijah

On 21/01/2023 01:55, Elijah Newren via GitGitGadget wrote:
From: Elijah Newren <newren@xxxxxxxxx>

Commit ce5238a690 ("rebase --keep-base: imply --reapply-cherry-picks",
2022-10-17) accidentally added some blank lines that cause extra
paragraphs about --reapply-cherry-picks to be considered not part of
the documentation of that option.  Remove the blank lines to make it
clear we are still discussing --reapply-cherry-picks.

Thanks for clearing up my mess!

Phillip

Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
---
  Documentation/git-rebase.txt | 2 --
  1 file changed, 2 deletions(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 00a9e22bc32..140c984d0ea 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -331,7 +331,6 @@ See also INCOMPATIBLE OPTIONS below.
  	upstream changes, the behavior towards them is controlled by
  	the `--empty` flag.)
  +
-
  In the absence of `--keep-base` (or if `--no-reapply-cherry-picks` is
  given), these commits will be automatically dropped.  Because this
  necessitates reading all upstream commits, this can be expensive in
@@ -340,7 +339,6 @@ read. When using the 'merge' backend, warnings will be issued for each
  dropped commit (unless `--quiet` is given). Advice will also be issued
  unless `advice.skippedCherryPicks` is set to false (see
  linkgit:git-config[1]).
-
  +
  `--reapply-cherry-picks` allows rebase to forgo reading all upstream
  commits, potentially improving performance.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux