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).


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


Reply via email to