I don't understand the issue, or why it's such a show stopper.
If the original programmer is using git, he should have a complete history of his code. They know the date (or thereabout) when the last version of the code "worked". Revert down to the a commit around that date.
For each dependency, do the same. Pull the dependencies repo down, revert to the last commit that was around the date of the working version, and use a new fork of that repo to get things back to the working state.
One by one, move the dependencies forward, resolving bugs as you go.
Another possibility is that the developer is using this as a convenient excuse to abandon a project where they bit off more than they could chew. $28K isn't a lot of money having already put in months of work and with potentially many months of work remaining.
The acid test will be if someone fixes their issue and says "Here you go, it's compiling again. Now just make sure you handle dependencies like this to keep everything working." Will the project be picked up again?
Unless he lost his local copy he wouldn't even need to guess what commit around the date he was at in each repo.
The info is stored in the ref-log of the local git repo, (as well as the dependencies' local repos).
So you could rewind all the repos to where they were at a particular date/time with:
`git co HEAD@{2012-11-26 18:30:00}` in each repo. If you run that same command in the project repo, and the dependency repos you should have a snapshot of the developers local checkout at that time.
HEAD could be a branch name or whatever ref. You can specify the time like ref@{2.days.3.hours.25.minutes.ago} as well, and these time specifiers work wherever you can specify a revision for example `git log -n1 master@{yesterday}`
You know, I haven't worked on that much software, and I've run into situations I at first thought impossible often enough that your comment just makes me laugh. :P
Unlikely? Surprising? Insane? Sure. But never call something impossible unless you can not only write down a formal proof for it but also verify your assumptions.
As other people are saying, maybe the original author made changes to the external dependencies he pulled in. Or maybe he's just bullshitting and indeed the code may have never worked. Or, sure, maybe the people trying to reconstruct the application went about it entirely the wrong way, like you suggest. It's just curious that you'd instantly pick the least charitable interpretation.
where commit-hash is the last known working commit.
Just do that with all the repos around the date it last worked. If there are alot of commits between the last working version and HEAD it is easier to do this then reverting each commit.
The problem is dependency which changed with any of the git-tracked content changing.
My interpretation:
1. Original author writes a program using Lua. Author downloads the latest version of Lua into his system and includes and links it. Note that Lua is not checked into his version control system nor does he note the used version.
2. Lua upstream does a backwards incompatible change
3. Author extends his local (old) copy of Lua
Result: An external dev will find no combination of Lua version and program revision which compiles. The original author seems to have lost his local modified Lua version.
You can probably spot various mistakes an experience software developer would avoid. The interesting point is that Go seems to encourage Step 1 nonetheless?
If the original programmer is using git, he should have a complete history of his code. They know the date (or thereabout) when the last version of the code "worked". Revert down to the a commit around that date.
For each dependency, do the same. Pull the dependencies repo down, revert to the last commit that was around the date of the working version, and use a new fork of that repo to get things back to the working state.
One by one, move the dependencies forward, resolving bugs as you go.