4 ms·

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 kno

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.

up_and_up 13y ago
What about branching and then doing: git reset --hard commit-hash 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.
thepicard 13y ago
I was also mystified as to how not a single one of them did this after alleged months of effort.
stdbrouw 13y ago
Maybe they did and it didn't work? You're giving them very little credit.
- etchalon 13y ago
  That wouldn't make any sense. Either the code worked at some point, or it didn't.
  - stdbrouw 13y ago
    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.
  - shardling 13y ago
    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.
    - thepicard 13y ago
      Unlikely, I would go with. It's unlikely that it couldn't be done. Based on the level of understanding in that thread, I'm not terribly surprised.
biot 13y ago
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?
bluehex 13y ago
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}` see: https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html https://www.kernel.org/pub/software/scm/git/docs/gitrevision...
qznc 13y ago
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?

up_and_up 13y ago

What about branching and then doing: git reset --hard commit-hash 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.

thepicard 13y ago

I was also mystified as to how not a single one of them did this after alleged months of effort.

stdbrouw 13y ago

Maybe they did and it didn't work? You're giving them very little credit.

etchalon 13y ago
That wouldn't make any sense. Either the code worked at some point, or it didn't.
- stdbrouw 13y ago
  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.
- shardling 13y ago
  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.
  - thepicard 13y ago
    Unlikely, I would go with. It's unlikely that it couldn't be done. Based on the level of understanding in that thread, I'm not terribly surprised.

biot 13y ago

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?

bluehex 13y ago

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}` see: https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html https://www.kernel.org/pub/software/scm/git/docs/gitrevision...

qznc 13y ago

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?