+1.
Shunning a commit is a bad idea.
But fossil will not differentiate type of content when shunning so not sure if
it can prevent shunning a commit.
> ----- Original Message -----
> From: Erlis Vidal
> Sent: 10/06/11 12:21 AM
> To: fossil-users@lists.fossil-scm.org
> Subject: Re: [fossil-users] git vs fossil again (was: why you should not
> shun)
>
> 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
