Re: [Gnu-arch-users] Re: Future of GNU Arch, bazaar and bazaar-ng ... ?

[Bruce Stephens]

Nathaniel Smith <address@hidden> 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.