Hi Ben. Thanks for the feedback.
> > - rewording commit messages, changing author, changing date, etc > > - amend-record does this, it's just not smart enough yet > > - rewording a patch needs no commute operations > > - dependencies should never prevent a reword operation > > - rewording a buried darcs patch only modifies other patches if > > there are "record --ask-deps" dependencies (which appear easy to > > adjust automatically) > > No, no, no! This is not possible, changing the meta data will change the > patch identity of an arbitrary number of other patches! I definitely want > to > have this disabled by default. Note that currently amend-record does not > mutate any patches other than the one I have explicitly chosen. > If I want to change the meta data for patch P, three are three possible scenarios: no patches depend on P, a patch Q implicitly depends on P, a patch Q explicitly depends on P (via darcs record --ask-deps). The first scenario is trivial and amend-record handles it well today. The second doesn't mutate Q, so Darcs should handle allow it but doesn't. The third triggers the cascading effects you mention. I agree that it should be disabled by default or generate a loud warning so the user isn't surprised. In any case, the changes are easy, so a fancy rebase mechanism isn't needed. Unfortunately, since Darcs refers to patches by their entire meta data, the cascading effect is worse than it needs to be. A unique patch identifier, independent of other metadata, would let us correct typos in P without mutating Q at all. Ignore-this "junk" might make a decent identifier, but that's for another discussion. > I'd say that even the existing version of amend-record would be improved by > issuing a warning (with a request for confirmation) if I change a patch > that > is also present in the default-repo. > > "Warning: This operation modifies a patch the exists in the default remote > repo. Are you sure? [yN]" > I agree. > > - combining arbitrary, adjacent patches > > - Darcs internals call this coalesce, but we have no UI for it > > - current amend-record is a special case of this, applied to only > > the top two patches > > To clarify: no, amend-record works fine for all patches that have no > dependents yet. > Right. One can view the current amend-record behavior as following these steps: commute patch A to the front, record working copy changes as patch C, coalesce A and C into A'. In that sense, today's amend-record is a special case of combining patches, namely the top two. Combining arbitrary, adjacent patches is a more general case. As long as A and C can be commuted to adjacent positions somewhere in the patch list, amend-record should work. For example, imagine having patches A and B where B depends on A. I want to amend changes C into A. C does not depend on B. Today's darcs fails this case because A can't commute to the front. However, we could commute C backwards to get ACB, then combine into A'B -- Michael
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
