I get the two points of view and I'm not saying one is right or wrong.
Modifying the history versus keeping everything as indeed happens (the
history after all)
Yesterday I was confused because I though the shun was done in the big file,
but indeed the shun was done in the commit also... will that modify the
history? I got the feeling that shunning a commit will change the history...
not sure about it, you tell me.
If I'm working under the premisses that the history cannot be changed, is
shunning a commit (in case it change the history) a valid operation? Maybe
fossil shouldn't allow to shun a commit, just individual files, if you
really want to shun all files in that commit, then fossil could allow that,
(shun --all) but that shouldn't touch ever the commit artifact..
Regards,
Erlis
On Wed, Oct 5, 2011 at 2:40 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> 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
>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
