To verify you've got the identical files on dev and staging, you can do some variation on

  find . -name *.pl | xargs md5sum | sort

and compare the output of that command from the two platforms. Assuming there's no configuration information in those files that differ between the environments, that should confirm or deny you have identical installations.

Restarting the web server meant something ten years ago, these days, not so much.

Apart from that, try to nail down why the bug that's been solved is reappearing -- what fix was made to solve that (it's documented in your git commit comments, right?). Maybe go back to basics and add a few logging lines to confirm that things are working as they should.

Good luck -- debugging is indeed a black art. :)

Alex


On Fri, Nov 7, 2014 at 3:19 PM, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
On Fri, Nov 07, 2014 at 01:14:44PM -0500, Scott Elcomb wrote:
> In a wee bit of a spot :(
>
> Have a git repo with squashed bugs coming back from the dead - and a
> conference tomorrow where early adopters are supposed to be trained on
> using the software.
>
> The strange thing is that there doesn't seem to be any indication of
> corruption or bad merges.  There are a few dangling commits, blobs
> and trees but they don't look to be related.
>
> Not having run into this scenario before I'm not quite sure where to
> start.  Any pointers or suggestions?

Some people think the way to check in file changes is to make their
changes, copy their file somewhere, then checkout the current version,
replace it with their version (without merging any other changes of
course), and check it in.  It's a great way to loose changes.

Of course people simply not understanding the merge resolution in git
can also cause things to get lost.

--
Len Sorensen


---
GTALUG Talk Mailing List - talk@gtalug.org
http://gtalug.org/mailman/listinfo/talk



--
Alex Beamish
Toronto, Ontario