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)