On 10/04/18 13:30, Johannes Schindelin wrote:
Firstly let me say that I think expanding the documentation and having
an example is an excellent idea.
+
+------------
+label onto
+
+# Branch: refactor-button
+reset onto
+pick 123456 Extract a generic Button class from the DownloadButton one
+pick 654321 Use the Button class for all buttons
+label refactor-button
+
+# Branch: report-a-bug
+reset refactor-button # Use the Button class for all buttons
+pick abcdef Add the feedback button
+label report-a-bug
+
+reset onto
+merge -C a1b2c3 refactor-button # Merge 'refactor-button'
+merge -C 6f5e4d report-a-bug # Merge 'report-a-bug'
+------------
+
+In contrast to a regular interactive rebase, there are `label`, `reset` and
+`merge` commands in addition to `pick` ones.
+
+The `label` command puts a label to whatever will be the current
s/puts a label to/associates a label with/ would be clearer I think.
Maybe s/whatever will be the current revision/the current HEAD/ an well?
+revision when that command is executed. Internally, these labels are
+worktree-local refs that will be deleted when the rebase finishes or
+when it is aborted.
I agree they should be deleted when the rebase is aborted but I cannot
see any changes to git-rebase.sh to make that happen. I think they
should also be deleted by 'rebase --quit'.
That way, rebase operations in multiple worktrees
+linked to the same repository do not interfere with one another.
+
+The `reset` command is essentially a `git reset --hard` to the specified
+revision (typically a previously-labeled one).
s/labeled/labelled/
I think it would be worthwhile to point out that unlike the other
commands this will not preserve untracked files. Maybe something like
"Note that unlike the `pick` or `merge` commands or initial checkout
when the rebase starts the `reset` command will overwrite any untracked
files."
Best Wishes
Phillip
