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:
>
> > Yann Dirson <ydirson@xxxxxxx> writes:
> >
> >> # 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 ?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html