Nathaniel Smith <[EMAIL PROTECTED]> writes: > Jan Hudec <bulb <at> ucw.cz> writes: >> I believe in some discussion before writing git, Linus actually requested >> that is should be ok to delete it and complained, that in monotone it was not >> easily possible (because of the shared storage). > > It isn't much harder to delete things in monotone than git -- you > never have to pull anything you don't want, and you can delete any > local revisions you pulled by accident...
I think the major part of what Linus wanted was a bit more involved than just deleting things. (He may well have wanted to be able to simply delete things as well; for legal reasons, for example.) I seem to remember he wanted to be able to ask a contributor to clean up a proposed patch before resubmitting it, and for the system to make that feasible. In darcs terms, he wanted to have "darcs amend-record", and "darcs unrecord" and similar features. So someone could take their working branch (where they might commit things several times a day) and reorganise the changes so that they make logical sense. That's deleting things, I guess, but it's deleting things that monotone doesn't really cater for. That I can see, anyway. (I can see how darcs can do it; I haven't looked at git to see if or how it does it---I presume it does, since Linus wanted that, though maybe he's changed his views, since.) [...] > It's also true that the convention, like for arch, is more to > save-and-ignore than delete-and-forget, but that's culture... Yeah. I can see advantages on both sides. If you deliberately discard history, then potentially you're discarding history that might be of interest later. On the other hand, if you don't, then you make it harder to see the wood for the trees (so it's harder to review proposed changes, for example), and you force everyone to copy around history where people put a file in "apps/foo/" then decide it ought to be in "lib/foo/" then decide it needs to be split after all (all within a couple of days) forever more. Or you encourage people to not commit often enough, or to use some other VCS to prepare changes that they later commit. _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
