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

On Tue, 09 Nov 2010 19:42:15 -0600
Jonathan Nieder [off-list ref] wrote:

Yann Dirson wrote:

quoted

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

Do you mean @{-1}?

quoted

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.

Mm, but intentionally dropping commits is common, no?

Yes, but for people new to the feature, who may not feel at ease right
away with it, it may make sense to get warned when some change will get
lost.

BTW, about people feeling at ease with "rebase -i", I often feel not
quite comfortable to explain why to reorder commits you have to use
this "rebase" feature which sounds so strange in itself to people used
to centralized VCS.  Would that make sense to have a standard command
to reduce some confusion, like (untested):

alias.reroll = rebase -i $(git merge-base HEAD @{upstream})

What would be nice is to be able to do

	git rebase --change-of-plans

and somehow get my editor of choice to open with the original todo
list (read-only) and the current todo list (read/write).

Well, a person can dream. :)

Well, that's not far from my own dreams of --back, --next and the
like :)

-- 
Yann Dirson - Bertin Technologies