On 2008.03.22 10:40:51 +0100, Jörg Sommer wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html