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

[Josh Triplett <josh@freedesktop.org>]

[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]

Linus Torvalds wrote:
> 
> 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.

> 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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]