I appreciate your comments but I have a somewhat different approach. (We
all have our own, no better or worse, just different.)
Regarding the removal of sensitive information committed by accident, I
would use the SHUN command since it directly targets the particular artifact
and not a whole branch.
I like my repos to keep history of 'success', at least as perceived at the
time. I do not want all the failed experiments, or left-over incomplete
work trails that may have eventually led to a working result -- only the
working result is of interest (even if it was thought to be working but
later was found to contain bugs). I want each commit to represent a 'clean'
step (as much as possible) towards some goal. Even backing out a change
becomes a lot easier if the related work is all together in a single (or
few) check-ins than spread over tens of them with many unrelated check-ins
in between.
I know I could hide everything that bothers me out of site. But just like
someone doesn't normally hide trash under the rug but takes it out, I want
to do the same. The parts that have become trash I want to permanently get
rid of. (Having enough room is no excuse for keeping ever more garbage in
your house indefinitely. You want to take it out at some point.) PURGE
seems to fit the bill.
Anyway, for now it seems that at least the --private branch idea works great
with PURGE so it covers me for what I like to do, and I'll stick to that
method until some better approach comes up.
PURGE with non-private branches works well for 'open ended' branches, while
it seems to have some issues when the branch to purge has been merged by
some other, at least in as much as not providing sufficient warning about
purging more than explicitly requested. You can always undo, but only if
you notice early enough and do not obliterate!
I don't consider purging as changing history, BTW. You still have the same
path travelled, and in the same order. You only get rid of irrelevant
details whose presence makes no difference. (Does history change if you
leave out the details about what breakfast Graham Bell had on the day he
invented his telephone?)
As for the command-line timeline, I wish it would only show the current
branch's by default, and use a short option (like -a) for seeing all.
(I'm still in search of a way to get rid of some existing older branches
that at the time I hadn't known about making them private, and are now
garbage 'polluting' my repos.)
Thanks.
-----Original Message-----
From: Reimer Behrends
Sent: Friday, December 18, 2015 9:38 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] PURGE: Is this result buggy or expected?
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
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
