> I do not think there currently is such an option, and not showing > the same object twice is pretty much fundamental in the operation of > the command, so it is unclear what the new feature should look like. > > Should it also show the same commit it encounters during its history > walk (remember, a history can have forks and merges in it) in > duplicates if it encounters it more than once? Should it show all > the subtrees and blobs in the tree of each commit, even if most of > them do not change from commit to commit? How does the user control > which ones are duplicated and which ones are to be visited only > once? How does the command line option used by the user to tell the > command to give such a choice look like? I was a bit brief in my description on Friday evening, due to the day & time. My naïve idea would be as follows: The option would be called something like "--include-all-object-names" and belong to the category of options that only make sense in combination with "--objects". That name (hopefully) already explains the intended behavior: * commits are not duplicated * as before, only changed blobs / subtrees are shown, however: * blobs / subtrees are duplicated in the output if they were previously shown with a different name > By the way, "rev-list" internally uses walking the commits > one-by-one, anyway ;-). I really should not write emails on Friday evening… What I meant was that I'd rather use a single call to git than one per commit. (The previous implementation of my hook then also queried all blobs for each commit, not just the changed ones, which contributed to the bad performance.)
