On Sun, Aug 10, 2008 at 03:53:01AM +1000, Alex Lance wrote: > IMO developing the functionality of making unpull/obliterate phone home > to the parent repo is a poor solution to the problem. What is the actual > problem that has led to the proposal of this solution?
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. Users who wanted to "just remove" a patch (a slightly but in this case very significantly different work flow) never considered to use the Unpull command because of its name. And users who did use Unpull in its intended way expected it to take as argument a repo to unpull from, and got generally confused and uncertain when it did not take such an argument. > 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. I will not say that it is the best solution for everything, but it has a certain simplicity and elegance to it. One feature often wished for was a way to ignore to pull some patches that darcs would ask for again and again. There was a suggestions to use a special key response in the interactive Pull dialogue to mark the patches and place them in an internal list or directory inside the darcs repo, but the current solution is the --complement option to Pull. The way to safely remove patches in darcs has always been to do it in a separate branch. 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 to Unpull would solve this problem nicely. If it is combined with the --intersection, --union, and --complement options it will become quite powerful. > Of course it's not like I'm volunteering to take on this work, so I'm Nonetheless it is useful to know how you, and others, think about darcs. Every person have their own model in their mind when they use darcs, so reports like this is our only chance to spot common misconceptions due to bad command names, misleading error messages, and so on. -- Tommy Pettersson <[EMAIL PROTECTED]> _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
