On 2008.03.22 10:40:51 +0100, Jörg Sommer wrote: > Hallo Björn, > > Björn Steinbrink schrieb am Sat 22. Mar, 02:52 (+0100): > > On 2008.03.22 02:19:42 +0100, Jörg Sommer wrote: > > > The current version of git-rebase--interactive shows the user the commits > > > coming from a merge. > > > > > > M---A---B > > > \ \ > > > o---o---+---o branch > > > > > > Rebasing branch on M with preserve merges gives the commits A and B. But > > > if you mark them for editing or remove them the rebase fails. You must > > > keep them as they are. It's useless to bother the user with these commits > > > and might lead to mistakes. > > > > Uhm, why do you completely remove the possibility to edit A instead of > > fixing the code so that the editing actually works? > > Because I didn't see why it's useful to edit A and create A' and merge in > A again, later. > > M---A---B > \ \ > C---D---+---o branch > > M---A--------------B > \ \ > C---B'---D'---A'---+---o branch Hm? Why do you have A' and B' on the other side of the merge? Using -p means that you deliberately _disable_ the linearization. The structure of the history is not supposed to change at all. You're just editing A and the merge should pull A(edited) and B in. Björn -- 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
