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

From: Josh Triplett <josh@freedesktop.org>
Date: Oct 23, 2006, 19:27 UTC
Message-ID: <453D17B5.6070203@freedesktop.org>
In-Reply-To: <Pine.LNX.4.64.0610230846420.3962@g5.osdl.org>

Linus Torvalds wrote:

Show 12 quoted lines

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

No, I didn't, primarily because the git log output I've scrutinized most carefully came from git log --pretty=raw, which doesn't rewrite parents even when pointed at a subdirectory.

Show 20 quoted lines

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

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.

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

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

- Josh Triplett