+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