Tony Papadimitriou wrote:
With all this talk about how to keep draft work out of the repo when
done with it, I started playing with the various methods mentioned.
I noticed the following, and I would like to know if this expected
behavior or some bug.
The following is only tangentially related to your question, but since I
probably started this by mentioning the purge command, I should now
explain why I think it's a good idea not to use it.
Basically, outside of emergencies (e.g. when you accidentally check in a
password or a multi-GB tarball), there is no need to remove stuff from
version control history. We're living in a time where hard drive
capacities are typically measured in terabytes and there is rarely a
need to save the few KBytes that your typical compressed changeset delta
amounts to.
The only thing that you need to be concerned about in practice is that
your history may become obfuscated by outdated commits. But the answer
to that is the ability to hide commits or filter your history, not to
wipe those changes from existence. This kind of nuclear option is almost
always unnecessary.
History deletion is a Git-specific thing for two reasons that do not
really apply to other version control systems.
1. Git uses purely functional data structures for its backend; the only
way to alter data after the fact (even to just repack commits) is to
create new objects and have the garbage collector clean up the objects
that have become unreachable. While that is a neat way of achieving
ACID-like properties without having to write a complex database backend,
this aspect of Git's backend has over time become a leaky abstraction
that has infected the frontend design.
2. Git lacks metadata for commits other than tags (and those are fragile
and do not scale). While hypothetically there is room for metadata in
commits (you can in theory add arbitrary headers to commits), this is an
option that has so far been eschewed. This makes it fairly difficult to
structure and filter history, because history is basically a soup of
anonymous objects.
I note that these problems are not unsurmountable; one could, for
example, retrofit Bazaar's frontend design on Git's backend pretty
easily and avoid the issues. My point is that deleting history – as
opposed to hiding or filtering it – is an artifact of Git's
implementation and there is no need for other VCSs to emulate it (in
fact, Mercurial is moving back towards an append-only model with its
evolve extension even in the face of history editing). And there is no
real upside to deleting history.
That said, I note that fossil's timeline command (as opposed to the
timeline in "fossil ui", which is very good) could really use some
usability improvements so that you can have a more informative view of
the history when you are using a terminal interface. Postprocessing
"fossil json timeline checkin" output is a bit cumbersome in the long run.
Reimer Behrends
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
