On Mon, 23 Oct 2006, Josh Triplett wrote: > > > I wonder if using "git-log --full-history -- $project" to let the core > > side omit commits that do not change the $project (but still give you > > all merged branches) would have made your job any easier? > > I don't think it would. We still need to know what commit to use as the > parent of any given commit, so we don't want commits in the log output > with parents that don't exist in the log output. And rewriting parents > in git-log based on which revisions change the specified subdirectory > seems like a bad idea. Umm.. You didn't realize that git log already _does_ exactly that? You need to rewrite the parents in order to get a nice and readable history, which in turn is needed for any visualizer. So git has long done the parent rewriting in order to be able to do things like gitk drivers/char on the kernel. And yes, that's done by the core revision parsing code, so when you do git log --full-history --parents -- $project you do get the rewritten parent output (of course, it's not actually _simplified_, so you get a fair amount of duplicate parents etc which you'd still have to simplify and which don't do anything at all). Without the "--full-history", you get a simplified history, but it's likely to be _too_ simplified for your use, since it will not only collapse multiple identical parents, it will also totally _remove_ parents that don't introduce any new content. So there are multiple levels of history simplification, and right now the internal git revision parser only gives you two choices: "none" (--full-history) and "extreme" (which is the default when you give a set of filenames). Linus - 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