--- Junio C Hamano <junkio@xxxxxxx> wrote: > Luben Tuikov <ltuikov@xxxxxxxxx> writes: > > > This patch allows history display of whole trees/directories a la > > "git-rev-list HEAD -- <dir or file>". I find this useful especially > > when a project lives in its own subdirectory, as opposed to being all > > of the GIT repository (i.e. when a sub-project is merged into a > > super-project). > > Both patches from you were seriously damaged. Check your MUA > before sending further patches, please. Yes, I'll take a look. > > They were trivial for me to apply by hand, so no need to resend > them. I like the effect of this one I am replying to very much. Junio, Linus, I took a comparative look with and without "--full-history", and FWIW, enabling full history just clobbers the output with a lot of unnecessary information. I.e. it shows merges which do not have direct consequence or change to the files in the path spec specified after the "--". I.e. no new, relevant information is being shown when "--full-history" is enabled. In fact the default git-rev-list case, simplify_history=1, still shows a merge here and there which doesn't have any direct changes into what is being sought, but the difference is about 48% less clobber. Can you consider the default case to be simplify_history=1, which is currently the default behaviour of git-rev-list. If not, is it possible to make this a configurable flag in gitweb, so that people can decide how much non-related history to show? I.e. I'd opt for the default case, no full-history. FWIW, I think that the original intention (had there been a choice) would've been to show only most relevant history, i.e. changes directly related to paths and files after the "--". Thanks, Luben - : 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