Alan Curry wrote: > Jim Meyering writes: >> >> tags 8423 notabug >> close 8423 >> thanks > > That's disappointing. I was looking forward to seeing a response to this > question. I also recently tried to find the origin of a bug with git bisect > and quickly ended up with an uncompilable mess. > > If you want to see a complete demonstration, I could make another attempt and > log it all. But if you're trying to tell us that checking out old versions > from the repository and compiling them shouldn't be expected to work... then > you're wrong.
Thanks for pointing that out. I should have explained here. This user posted the same request to at least two other mailing lists and there was a fine response on at least one of those others. Here's some explanation and an outline: coreutils-6.7 was released on 2006-12-08, which was before we had a gnulib git submodule. Actually, that was back when bootstrap would pull the gnulib sources via cvs. coreutils itself had switched to git only two months before. Hence, without a submodule, and with no other record of which gnulib commit was used, you'll have to resort to dates to find approximately which gnulib was used. Or compare with the release tarball. Since cvs access to gnulib may not do what you want, I suggest using a ../gnulib directory. You'd git-reset it to a commit from the date corresponding to 6.7 and then reference ../gnulib via the GNULIB_SRCDIR=../gnulib envvar setting that bootstrap uses. From there on, you'll just have to debug problems as you find them. There is no general recipe.
