On Mon, Aug 11, 2008 at 02:22:48AM +0200, Tommy Pettersson wrote: > On Sun, Aug 10, 2008 at 03:53:01AM +1000, Alex Lance wrote: > > The original Upull command was intended to be used to undo a > resent Pull. Back then it was not common practice to widely > remove changes from a revision control system's repository. The > merits of the Unpull command is that both its name and action > mimics this work flow very well. But there were some problems > with the Unpull command, which is why Obliterate was invented.
Having the "unpull" command be an alias to the "obliterate" command does not seem like a good idea to me. The former implies a level of safety that the latter does not. > > 2) Change the behaviour of the "obliterate" command so that: > > > > a) Instead of un-applying and then deleting a patch, it un-applies a > > patch and then moves the patch bundle into a "trash" directory within > > the > > repo. > > Darcs already has a very powerful mechanism for this; branches. The purpose of obliterate is self-evident: It destroys patches. It's functionality is much like the 'rm' command. And like the rm command, it would be smarter to give it sensible/safe defaults. > But when mixing patches from different branches it can sometimes be > annoying to keep track of which patch comes from which repository. The > extra argument [of a source branch] to Unpull [from] would solve this > problem nicely. If it is combined with the --intersection, --union, and > --complement options it will become quite powerful. Ok it is clear to me that you are talking about adding new functionality that extends unpull - functionality that would actually turn "unpull" into a new and separate command from "obliterate". My proposal suggested removing "unpull" altogether, but you have shown me that there could perhaps be a reason for it to exist. However, if the additional functionality that you suggest is not widely desired, then I do think it would be wise to get rid of "unpull" ... and *regardless* I do think that the rest of my proposal has merit: - modify obliterate so that it un-applies a patch, creates the patch bundle and just *moves* said patch bundle to _darcs/trash/ ... by default. - modify obliterate to accept some sort of a "--forever" argument which *completely removes* the patch (i.e. the way it currently functions) instead of moving it to the _darcs/trash/ - ensure any patches in _darcs/trash/ can be easily `darcs apply`-ed (i.e. recovered). But anyway. It's not like I've ever been bitten by obliterate, although the other day I did `darcs send` some patches onwards, and then nearly obliterated them straight away, and it was lucky that I didn't since the email never showed up (unrelated MTA problems). Cheers, Alex _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
