Gluster blog stories provide high-level spotlights on our users all over the world
There are no shortage of ways to look at individual changes to individual lines in a Git repository. But what happens if you want to see what an entire file looked like, as of a particularly “long time ago”, in the absence of an exact commit message or date?
|Unfortunately, alot of times, we don’t know the exact hash of the commit we want to investigate. In this very breif and embarrassingly simple post I’ll outline a simple strategy for finding the “last version that probably worked”.|
**NOTE: If you have to do this alot – there is probably something systemically wrong in your dev process.**
Lets consider the following scenario:
1) You know a file used to work, about 2 or 3 months ago.
2) You want to see how it was different
3) Line by line structural changes don’t help – the file has since been restructured. Methods were moved around. Objects were refactored out, etc…. So you want the ENTIRE file as of a certain state. In order to do this, you need to use “date” as a search filter.
First: You have to find out the “state” of the file which you are interested in. In git, this means finding the commit hash.
The simple method, if you trust the commiters: “git log”.
The “git log” command will give all commits related to a file:
git log src/myfilethatchanged.clj
Will yield :
Date:Dec 25 1:1:1 2012 +010
Ripping out everything related to this really important function b/c its christmass
However, this is hardly the case. Rather – commit messages are often (at best) highly granular, or (at worst) non existent. Very rarely will a commit define a possible bug that you can search for by eye using git log.
In the (common) case where you don’t know quite which commit you are interested in, you can simply use”git blame | grep <date regex>” to view several file states around the time you are interested in:
git blame src/myfilethatchanged.clj | grep jayunit100 | grep 2012-
At this point, you will get a list of git commit ids, followed by the commit contents. Not particularly useful for fine grained debugging. But it narrows it down to the right date!
a28jcz0a jayunit100 2012-09-22 18:43:58 +0200 934 //this is a bad idea.
e36fb8c9 jayunit100 2012-09-22 17:13:11 +0200 934 //some other inoccous line of code
Ah ^^ this looks like the commit which might have been done at the time that everything was working correctly.
Now, finally, here is how we write the entire file at that state in time out:
git show e36fb8c9:src/myfilethatchanged.clj > myfilethatchangedOLD.clj
Thus, it is super easy to be a source dectective by simply using “git blame” along with “git show” to recreate a “whole” version of a working file at the time of an ancient commit, even if you don’t know the exact date/hash of the commit.
The trick is to first use “git blame”with, for example, a simple grep to scan for the date range you are interested in. Then, we find some candidate commits of interest, followed by “git show” to recover the exact state of the file at a given timepoint.
2020 has not been a year we would have been able to predict. With a worldwide pandemic and lives thrown out of gear, as we head into 2021, we are thankful that our community and project continued to receive new developers, users and make small gains. For that and a...
It has been a while since we provided an update to the Gluster community. Across the world various nations, states and localities have put together sets of guidelines around shelter-in-place and quarantine. We request our community members to stay safe, to care for their loved ones, to continue to be...
The initial rounds of conversation around the planning of content for release 8 has helped the project identify one key thing – the need to stagger out features and enhancements over multiple releases. Thus, while release 8 is unlikely to be feature heavy as previous releases, it will be the...