On Friday 28 of September 2012 21:46:46 Darrell Anderson wrote:
> 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.

Switching the whole tree is fairly simple. First of all - you do not need git 
reset, but git checkout. As follows (on top of tree):

  git checkout _revision_ && 
  git submodule update && 
  git submodule foreach "git submodule update"

The first - "checkout" - is used to switch to the desired version (see below).
Second - "submodule update" - ensures switch all modules comply with the state 
of the tree version. Third - "submodule foreach ..." - ensures switch all 
nested modules comply with the state of the tree version.

Alternatively, you can simplify using --recursive:

  git checkout _revision_ && git submodule update --recursive

And now, how to determine the required _revision_. To your original question 
probably the simplest answer is: "@{2012-04-01 00:00:00}"

  git checkout "@{2012-04-01 00:00:00}" && git submodule update --recursive

Git according to the date determines, in which revision was at given date and 
time, performs checkout root of tree to appropriate state for this revision 
and subsequent "submodule update" ensures all modules to switch also to the 
appropriate state.

Is it sufficient?

Slavek
--