Hi all,

My two cents:

I like phrase *commit jungle* and sometimes would like to revert some
commits or "re-commit" things a bit different. I also suppose that it
is not that rare when people commit something by mistake or something
which has not been tested enough. On the other hand my gut feeling is
that (apart from what was said before) changing history is just bad
and should be avoided.

Perhaps the tooling you are talking about is just a filtered commit
view. I mean if fossil allowed users to attach a tag (e.g. "private")
to commits to say that they aren't visible in the timeline by default,
we could avoid the jungle and also keep exact history by giving users
a "full view" option where everything is visible (as it is shown
currently).

Also the thing is that some commits tend to be more important than
others (you usually tag somehow like version X.Y). But in this context
it's perhaps better to say that some commits are much less important
than others (e.g. correcting a spelling mistake in the comments). I
think that the filtered view would allow to hide these.

Michal would that be enough for you to match with the git rewriting
option (which I'm not aware of)?

  Cheers,
  Jacek


2012/9/14 Michal Suchanek <hramr...@gmail.com>:
> On 14 September 2012 15:52, Richard Hipp <d...@sqlite.org> wrote:
>>
>>
>> On Fri, Sep 14, 2012 at 9:35 AM, Michal Suchanek <hramr...@gmail.com> wrote:
>>>
>>>
>>> The thing to which promoters of immutable history are blind is that
>>> while exact history record of development of particular feature might
>>> be interesting and educational it is not the primary purpose if VCS.
>>
>>
>> The exact preservation of history is considered "best practice" for
>> high-reliability and safety-critical systems.  Fossil, for example, was
>> designed to meet the VCS requirements of DO-178B level A.  (Ref:
>> http://en.wikipedia.org/wiki/DO-178B)
>>
>> You might not think that exact preservation of history is one of the primary
>> purposes of VCS, but not every project manager thinks exactly like you.
>>
>
> I don't think that's a bad goal. The failure I see is inadequate tools
> for working with the resulting commit jungle. And if you were really
> obstinate about that then fossil fails in that it does not record
> *every* change, it requires explicit commits.
>
> Thanks
>
> Michal
> _______________________________________________
> 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

Reply via email to