Re: [PATCH v3 0/4] rebase -i: mark commits that begin empty in todo editor

> Changes since v2:
> 
>   * Addressed feedback from Junio in patch 2, including moving some of the
>     wording to the new patch (see next point)
>   * Edited jt/rebase-allow-duplicate to include the changes Jonathan
>     mentioned on the list, then rebased it on top of this series, and made
>     the related options mention each other.
> 
> Elijah Newren (3):
>    rebase -i: mark commits that begin empty in todo editor

> 
> Jonathan Tan (1):
>    rebase --merge: optionally skip upstreamed commits
> 
>   Documentation/git-rebase.txt      | 70 +++++++++++++++++++++-------
>   builtin/rebase.c                  | 24 +++++++---
>   sequencer.c                       | 14 +++++-
>   sequencer.h                       |  4 +-
>   t/t3402-rebase-merge.sh           | 77 +++++++++++++++++++++++++++++++
>   t/t3421-rebase-topology-linear.sh | 10 ++--
>   t/t3424-rebase-empty.sh           | 36 +++++++++++++++
>   7 files changed, 202 insertions(+), 33 deletions(-)
> 
> 
> base-commit: 274b9cc25322d9ee79aa8e6d4e86f0ffe5ced925
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-757%2Fnewren%2Frebase-mark-empty-v3
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-757/newren/rebase-mark-empty-v3
> Pull-Request: https://github.com/git/git/pull/757
> 
> Range-diff vs v2:
> 
>   1:  0d94eea376a = 1:  0d94eea376a rebase -i: mark commits that begin empty in todo editor
>   2:  e15c599c874 ! 2:  3a5bedc68d6 rebase: reinstate --no-keep-empty
>       @@ Commit message
>        
>            Commit d48e5e21da ("rebase (interactive-backend): make --keep-empty the
>            default", 2020-02-15) turned --keep-empty (for keeping commits which
>       -    start empty) into the default.  That commit viewed this, though as
>       -    turning that flag into a no-op.  As such, --no-keep-empty was translated
>       -    into undoing a no-op, i.e. also a no-op.  The logic underpinning that
>       -    commit was:
>       +    start empty) into the default.  The logic underpinning that commit was:
>        
>              1) 'git commit' errors out on the creation of empty commits without an
>                 override flag
>       @@ Commit message
>            look really weird despite making perfect sense (the first will drop
>            commits which become empty, but keep commits that started empty; the
>            second will keep commits which become empty, but drop commits which
>       -    started empty).
>       +    started empty).  However, --no-keep-empty was named years ago and we are
>       +    predominantly keeping it for backward compatibility; also we suspect it
>       +    will only be used rarely since folks already have a simple way to drop
>       +    commits they don't want with an interactive rebase.
>        
>            Reported-by: Bryan Turner <bturner@atlassian.com>
>            Reported-by: Sami Boukortt <sami@boukortt.com>
>       @@ Documentation/git-rebase.txt: See also INCOMPATIBLE OPTIONS below.
>        -always dropped.
>        +Note that commits which start empty are kept (unless --no-keep-empty
>        +is specified), and commits which are clean cherry-picks (as determined
>       -+by `git log --cherry-mark ...`) are detected and dropped as a preliminary
>       -+step (unless --keep-cherry-picks is passed).
>       ++by `git log --cherry-mark ...`) are always dropped.
>         +
>         See also INCOMPATIBLE OPTIONS below.
>         
>       @@ Documentation/git-rebase.txt: See also INCOMPATIBLE OPTIONS below.
>        -	to halt.
>        +	Do not keep commits that start empty before the rebase
>        +	(i.e. that do not change anything from its parent) in the
>       -+	result.  For commits which become empty after rebasing, see
>       -+	the --empty and --keep-cherry-pick flags.
>       ++	result.  The default is to keep commits which start empty,
>       ++	since creating such commits requires passing the --allow-empty
>       ++	override flag to `git commit`, signifying that a user is very
>       ++	intentionally creating such a commit and thus wants to keep
>       ++	it.
>         +
>        -See also BEHAVIORAL DIFFERENCES and INCOMPATIBLE OPTIONS below.
>       ++Usage of this flag will probably be rare, since you can get rid of
>       ++commits that start empty by just firing up an interactive rebase and
>       ++removing the lines corresponding to the commits you don't want.  This
>       ++flag exists as a convenient shortcut, such as for cases where external
>       ++tools generate many empty commits and you want them all removed.
>       +++
>       ++For commits which do not start empty but become empty after rebasing,
>       ++see the --empty flag.
>       +++
>        +See also INCOMPATIBLE OPTIONS below.
>         
>         --allow-empty-message::
>   3:  ee5e42361fc = 3:  5c8863b9d34 rebase: fix an incompatible-options error message
>   -:  ----------- > 4:  20d3a50f5a4 rebase --merge: optionally skip upstreamed commits
>