Message: previous - next
Month: September 2012

Re: [trinity-devel] Revert GIT to a specific date

From: Darrell Anderson <humanreadable@...>
Date: Fri, 28 Sep 2012 12:46:46 -0700 (PDT)
> 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.
> 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.
> I want to start as far back as April 1 and then proceed
> forward until the bug reappears.
> When I do a git log I want the sources to actually reflect
> the state of that date and not the illusion of that date. I
> need to do this to the whole repo and not just a specific
> package module.

Does anybody know how to do this?

The root problem is commits are module based. The Trinity GIT repo consists of more than 110 modules. To my knowledge there is no easy one-step 'git reset --hard {commit}' option available to revert an entire local Trinity repo to a previous state because commit hashes are not common among all Trinity modules.

Everything I read online addresses using 'git reset --hard {commit}' but is always focused on projects with only one repo. The Trinity repo is really 110+ repos.

The only option I see thus far is writing a script to query each Trinity module for the last commit on a specific date and have the script perform a 'git reset --hard {commit}' for each module.

Is there a way to perform 'git reset --hard' based on date rather than commit?

The 'git log --until" command queries the last commit on a specific date. I don't know how to extract the commit hash from that query.

To troubleshoot regressions, a future solution probably creates and archives a set of tarball snapshots with each resync of the local repo.