On 28 Sep 2012, Darrell Anderson told this:
I realize that resetting my local repo will mean a
bandwidth hit when I restore everything. :)
No, don't think so. You already have a copy of the local
repo, and you're not deleting any commits... So I think you could
reset up back to {HEAD}.
That is where I'm confused. I _do_ want to delete all commits more
recent than the date to which I reset. Otherwise I am building
packages with the same current sources. I won't accomplish anything. I
am looking for a way to reset my local repo to commit xxxxxxxx and
delete all commits after that date. The final result is a local repo
that looks exactly as GIT did on the day of commit xxxxxxxx.
This is possible, but...
I want to do this to troubleshoot a difficult bug.
After installing a
GIT package set from several months ago, I know the bug did not exist
then. Something happened thereafter. I want to build packages from my
local repo but the sources must look exactly the same as whatever date
I choose.
... this has nothing to do with deleting commits. It's just checking out
an earlier revision, something that git can of course do, or what's the
point of a version control system? Making the sources look exactly the
same as on some specific date is not something that is very well
defined, because a git repository is a slice through a distributed
system, so there is no single atomic view of the repository as at a
given date. But you can do
git checkout $(git log --until $date -n 1 --pretty=%H)
git submodule update
which will at least give you *a* view of the repo as on that day
(specificically, the state of the repo when the first commit with that
date hit it).
Later commits still exist in the repository: you are just on a 'detached
HEAD', i.e. not on any branch. Don't commit in this state: do a 'git
checkout master && git submodule update' (or some other branch name
instead of master) first.
But you don't want to do this anyway: you want to use 'git bisect',
which is designed for this sort of binary-searching for bugs with
unknown origin. (Note that after every 'git bisect good/bad' you will
need to do a 'git submodule update' to bring the submodules up to date
properly.)
I want to start as far back as April 1 and then
proceed forward until
the bug reappears.
If you've deleted all commits after that date, proceeding forward would
be impossible: the commits are gone.
--
NULL && (void)