Linus Torvalds wrote:
quoted text
>=20
> On Mon, 23 Oct 2006, Josh Triplett wrote:
>>> I wonder if using "git-log --full-history -- $project" to let the cor=
e=20
quoted text
>>> side omit commits that do not change the $project (but still give you=
=20
quoted text
>>> 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 t=
he
quoted text
>> parent of any given commit, so we don't want commits in the log output=

quoted text
>> with parents that don't exist in the log output.  And rewriting parent=
s
quoted text
>> in git-log based on which revisions change the specified subdirectory
>> seems like a bad idea.
>=20
> Umm.. You didn't realize that git log already _does_ exactly that?

No, I didn't, primarily because the git log output I've scrutinized most
carefully came from git log --pretty=3Draw, which doesn't rewrite parents=

even when pointed at a subdirectory.

quoted text
> You need to rewrite the parents in order to get a nice and readable=20
> history, which in turn is needed for any visualizer. So git has long do=
ne=20
quoted text
> the parent rewriting in order to be able to do things like
>=20
> 	gitk drivers/char
>=20
> on the kernel.
>
> And yes, that's done by the core revision parsing code, so when you do
>=20
> 	git log --full-history --parents -- $project
>=20
> you do get the rewritten parent output (of course, it's not actually=20
> _simplified_, so you get a fair amount of duplicate parents etc which=20
> you'd still have to simplify and which don't do anything at all).
>=20
> Without the "--full-history", you get a simplified history, but it's=20
> likely to be _too_ simplified for your use, since it will not only=20
> collapse multiple identical parents, it will also totally _remove_ pare=
nts=20
quoted text
> that don't introduce any new content.

Considering that git-split does exactly that (remove parents that don't
introduce new content, assuming they changed things outside the
subtree), that might actually work for us.  I just checked, and the
output of "git log --parents -- $project" on one of my repositories
seems to show the same sequence of commits as git log --parents on the
head commit printed by git-split $project (apart from the rewritten
sha1s), including elimination of irrelevant merges.

quoted text
> So there are multiple levels of history simplification, and right now t=
he=20
quoted text
> internal git revision parser only gives you two choices: "none"=20
> (--full-history) and "extreme" (which is the default when you give a se=
t=20
quoted text
> of filenames).=20

I don't think we need any middle ground here; why might we want less
simplification?

- Josh Triplett