On Tue, Nov 03, 2009 at 09:31:34 +0100, Florent Becker wrote: > >> In the same vein, I think I'll add an unapply command to unpull a > >> patch and keep a copy of it as a bundle (which then can be used as a > >> lightweight darcs stash). I know these would be two more commands, but > >> they are very useful, easily learned (almost the same arguments as > >> existing commands), and with clear semantics. > > > > I think I'd prefer to just have darcs obliterate do this (save the patches > > it unapplies) automatically, rather than have a separate command that > > amounts to send -o + obliterate. > > That makes sense. This would be the -o/-O option to obliterate, and putting > obliterate -O _darcs/trash in the prefs file would then be the smart thing > to do.
This makes me wonder if darcs pull -o/-O would be a useful alternative
to darcs fetch.
As usual, I'm going to put on a little bit of pressure to avoid adding
new commands and new features. Do we really need a fetch (or a darcs
pull -o/-O) command in practice? What's the use case?
That said, I'm afraid that for patch, I'm not really able to provide the
kind of resistance that this project deserves. I think we may need to
find a better "Mr. No" than me because I personally don't mind the idea
so much.
It seems to share the sort of conceptual integrity that (IMHO) makes
Darcs so nice to use. It does add a bit more symmetry too
get / put
pull / push
fetch / send
where fetch and send both work with bundles. There's also the idea you
mentioned of making darcs pull work from bundles.
pull / unpull
revert / unrevert
apply / unapply (could also be an alias for obliterate)
Ganesh pointed out is that we can then explain pull as being fetch +
apply, much like [I'd add] we could explain push as send + apply, or
obliterate as unrecord + revert, or amend as unrecord + record.
Finally: another option to consider would be to implement darcs plugins:
http://bugs.darcs.net/issue1504
This would give us a way to field test new commands...
OK! So with all that blathering out of the way, how do we fit all these
pieces together? The point really isn't to resist features at all
costs, it's to preserve the usability of Darcs, the feeling that you can
do a lot of things with a very small number of ideas, but conveniently
at that. We want conceptual integrity; we want to keep the set of
commands small (darcs must remain the antithesis of git in this
respect), but we also want to make sure that there is enough
functionality that people don't have to combine commands in really crazy
ways just to do basic things.
--
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
