On Mon, 23 Oct 2006, Josh Triplett wrote:
quoted text
> 
> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html