Re: [PATCH] git-rebase--interactive.sh: Add new command "shell"

On Mon, Nov 08, 2010 at 01:49:44PM -0800, Kevin Ballard wrote:

On Nov 8, 2010, at 10:31 AM, Junio C Hamano wrote:

quoted

Yann Dirson [off-list ref] writes:

quoted

#  e, edit = use commit (if specified) but pause to amend/examine/test

When an end user is given

   pick one
   pick two
   pick three
   ...

and told the above, would it be crystal clear that, if he changed the insn
sheet to

   pick one
   edit
   pick three
   ...

then he will _lose_ the change made by foo, or will the user come back
here and complain that a precious change "two" is lost and it is git's
fault?

On the one hand, once someone understands what the todo list is actually
doing, then it should be instantly obvious that removing the reference to
a commit will remove that commit entirely. On the other hand, I agree it
may be confusing to new git users (or new rebase users). Do you have an
alternative solution in mind?

Maybe restating in an explanatory paragraph something like:

|Keep in mind that any commit in the original todo list, that would
|not be there after your edits, would not be included in the resulting
|rebased branch.  In case you realize afterwards that you need such a
|commit, you can still access it as an ancestor of @{1}, see
|git-reflog(1) for details.

Maybe we could list a copy of the todo list in the comments, as a
reference for double-checking.  Such a list could even be used for a
final check before applying, that would ask confirmation if the set of
patches has changed, and offer to edit again.  The same config item
(eg. advice.interactiveRebase ?) could be used to hide the note and
the check.

Now making "rebase -i" possibly interactive may cause problems, for
any porcelain scripts above it.  Not sure it'd be the way to do it.
Maybe add a "check" command to be inserted at bottom of todo list to
activate it, that would be here by default but commented out ?