Junio C Hamano wrote: > I tend to agree with Michael (modulo s/ culture/'s early&/) here. Many > documents written in the early days, the "tutorial" document by Linus > being the most prominent example, were written in a way to focus exposing > the implementation details to show how simple the structure is. [...] >> Probably the more relevant question: what do you want to do about it? > > Continue the current course of encouraging the use of plumbing commands > and not looking at the low-level implementation detail. Perhaps help > people update their documents, moving stale descriptions into "historical > note" sections. Thanks for deciphering. So here’s a list from a quick Google search for “.git/refs” (alas, the search engine is not strong enough to return the right hits for “git "layering violation"”). Some nice pages here, actually. . http://linux.yyz.us/git-howto.html#diff_branch . http://www.lostechies.com/blogs/jason_meridth/archive/2009/06/07/git-for-windows-developers-git-series-part-3.aspx . http://gitfu.wordpress.com/2008/05/25/git-describe-great-another-way-to-refer-to-commits/ . http://www-cs-students.stanford.edu/~blynn/gitmagic/ch08.html . http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html and http://code.google.com/p/support/wiki/ImportingFromGit . http://blog.stevecoinc.com/2010/02/stupid-git-tricks.html It would be nice to find ways to suggest updates (but please coordinate so as not to flood the authors with mail). There are a lot of instances of “rm -r .git/refs/original” after running filter-branch, too. Maybe filter-branch ought to provide some synonym for eval "$( git for-each-ref refs/heads/\* --shell --format='git update-ref -d %(refname) &&' && echo : )" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html