Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges

From: Linus Torvalds <torvalds@osdl.org>
Date: Oct 23, 2006, 15:52 UTC
Message-ID: <Pine.LNX.4.64.0610230846420.3962@g5.osdl.org>
In-Reply-To: <453C96C9.4010005@freedesktop.org>

On Mon, 23 Oct 2006, Josh Triplett wrote:

Show 10 quoted lines

> 
> > 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