> If a merge has been cherry-picked we cannot update it as we don't record > which parent was used for the pick, however it is probably not a problem > in practice - I think it is unusual to amend merges. I've read and reread that sentence several times and don't fully understand it. Could you elaborate? It sounds scary, though. With the evolve command, amending merges will need to be supported. If you create a merge and then amend one of its parent commits, the evolve command will need to rebase the merge and point one or both parents to the replacement instead. - Stefan On Tue, Nov 20, 2018 at 5:03 AM Phillip Wood <phillip.wood@xxxxxxxxxxxx> wrote: > > On 15/11/2018 00:55, sxenos@xxxxxxxxxx wrote: > > From: Stefan Xenos <sxenos@xxxxxxxxxx> > > > > +Obsolescence across cherry-picks > > +-------------------------------- > > +By default the evolve command will treat cherry-picks and squash merges as being > > +completely separate from the original. Further amendments to the original commit > > +will have no effect on the cherry-picked copy. However, this behavior may not be > > +desirable in all circumstances. > > + > > +The evolve command may at some point support an option to look for cases where > > +the source of a cherry-pick or squash merge has itself been amended, and > > +automatically apply that same change to the cherry-picked copy. In such cases, > > +it would traverse origin edges rather than ignoring them, and would treat a > > +commit with origin edges as being obsolete if any of its origins were obsolete. > > If a merge has been cherry-picked we cannot update it as we don't record > which parent was used for the pick, however it is probably not a problem > in practice - I think it is unusual to amend merges. > > Best Wishes > > Phillip
