On Tue, 09 Nov 2010 19:42:15 -0600
Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Yann Dirson wrote:
>
> > |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}?
>
> > 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
--
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