* zooko <[EMAIL PROTECTED]> [2007-11-04 08:47:48 -0700]: > But by the way, I still believe that "unpull" is a confusing name > that should be deprecated. If you create a patch and push it and > then "unpull" it what happens? Well, what happens is fine, except > that the user is confused and doesn't understand why you can unpull > something that you didn't pull. This isn't just my own personal > intuition -- it is something that I have personally witnessed more > than once. (It also matches my own personal intuition.)
On the one hand, the name "unpull" makes perfect sense to me. "pull" integrates a new patch (or patches) into a repository, "unpull" eliminates patches from a repository, regardless of how those patches were integrated in the first place. If you think of it as the inverse of a "pull" operation, rather than just an "undo" feature for "pull", then this seems to make sense. On the other hand, apparently most people don't find this nearly as intuitive as I do; and I believe this is why the "obliterate" alias is now the preferred form of the command, and "unpull" is now a hidden alias. So, I think your problem should already be solved. > > Another measure, not much more complicated, would be a feature to > > track > > whether a patch has been distributed. Every repository could simply > > have a list of not-yet-distributed patches and protect against > > unrecording or amending patches that have been distributed. > > +1 Hopefully there would still be the option to override this protection. I amend / unrecord distributed patches fairly frequently where patches have been "distributed", but only to repositories under my own control; for example, pushing patches between local branches. -- mithrandi, i Ainil en-Balandor, a faer Ambar
signature.asc
Description: Digital signature
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
