On Wed, 5 Oct 2011 11:12:31 -0700
Mike Meyer <m...@mired.org> wrote:
> > That sort of "we don't need it, we don't need it" mantra is a
> > typical case of the famous "Blub paradox".
> > I mean, if we have two DVCS tools one of which makes you able to
> > rewrite history and another one which doesn't, the first one is more
> > powerful _in this particular respect_. It's as simple as that.
> > By supporting a feature, the tool does not force you to employ that
> > feature in your workflow.
> First, note that there is a difference between "rewriting history",
> which is what git supports, and "deleting unwanted items", which is
> the request that started this.
Correct.
> Second, that a feature doesn't affect you if you "just don't use it"
> is a fallacy. Sure, I think history should be sacrosanct, so I won't
> use rebase even if it's available. That doesn't stop others on the
> project (who don't agree with me) from using it . The only way to
> make sure that doesn't happen is to not have the feature available
> *at all*.
I'm not entirely convinced.
Look at the workflow used by the Git team: they maintain the set of
well known branches, of which the only one, named "pu" ("proposed
updates"), is allowed to be rebased and that's actually what happens
with it each time the new release is made--it's cut from the master
afresh. I mean, while every committer has `git rebase` at their
disposal and knows how it works this does not mean they go off and break
the repository with rebases. So your point is only really valid when
the project is run by a bunch of idiots or complete newbies.
> Finally, having a feature that powerful available tends to cause the
> API to *not* include safe versions of common tasks that that
> dangerous feature handles. To see what I mean, take a look at
> mercurial, which shares the fossil philosophy, but provides a
> (disabled by default) rebase command. It has a number of commands
> (*not* disabled by default) for tasks that are handled in git using
> rebase. Unlike rebase, those commands are safe, in that mistakes with
> them can't wreck your repo the way a mistake with rebase can. It may
> not make a difference if you never make mistakes, but in that case
> you don't need rebase.
Git handles it from the opposite direction by having "the reflog".
But I find this point to be valid, yes, safety nets are a must when it
comes to handling precious data. BTW I'm a fan of `fossil undo` for
that matter.
> Bottom line: while "more features" may imply "more powerful", it
> doesn't imply "better".
Moot point.
I really miss Git's "index" and `git add --patch` here.
Is Fossil better than Git in this respect by not having those "more
features"? Surely it completely is in the eye of the beholder.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
