28 Sep
2012
28 Sep
'12
11:30 p.m.
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
--