In article <7vk4v0fqts.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Ron Garret <ron1@xxxxxxxxxxx> writes: > > > My actual use case is very complicated, but here's a simplified version: > > > > Suppose I'm using git as a back-end for a wiki. I want to look at the > > state of the entire wiki as it was in some point in the past, and I also > > want to be able to look at the diffs between individual pages as they > > were then and as they are now. > > Don't think you are so special ;-) Never. :-) > "git checkout $that_old_commit" was > invented _exactly_ for that use case. You can look around from that > state, and when you are done sightseeing, you can come back by doing a > "git checkout master" (or whichever branch you want to be on). Yes, that's what I would have expected. Except that it not only updates my working tree, it updates my head also, so git diff doesn't give me the diffs that I want. (This makes sense for the usual use case.) > You don't necessarily have to check out an old state if the only thing > you are interested in is to review how the contents changed over time. > Use "git log -p" (from the current tip) for that. > > If you chose to have an old checkout and then traverse the changes over > time leading to the current tip, you would say "git log -p ..master" > instead. There's also this: git rev-list HEAD -- [filename] git ls-tree [some-hash-from-the-list-above] Then for each line in the result: git cat-file blob [hash] > [filename] which seems like a horrible hack, but actually does what I want. rg -- 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