Re: Unexpected behavior in git-rev-list

On Wed, 21 Sep 2005, Linus Torvalds wrote:

Anyway, I've seriously considered adding a mode to "git-rev-list" that
automatically avoids following the parents that aren't relevant for a
certain set of files.

Ie if you did

	git-rev-list rev1 rev2 ^rev3 ^rev4 .. pathname

it would only show the revisions that actually _change_ the pathname.

It's not entirely trivial. The biggest bummer is that we'd have to fake
out the parent info (ie the "parent" would have to be the previous entry
that changes it, not the real one).

How about a program that made the fake thing real? That is, actually wrote 
to the database the entire history with only those paths included, and 
only commits that change those paths.

This would be exactly the right thing for the people who want kbuild to be 
a separate project from the kernel, because "the kbuild project", with 
full history, could be automatically generated.

For that matter, Sam could actually use that repository for maintaining 
kbuild, because if mainline merges that instead of merging the present 
kbuild-in-kernel repository, it'll be exactly the same. He could pick up 
stuff from the mainline by subsetting mainline.

In fact, this operation would allow Junio to push gitk changes upstream, 
as well; "git subset -w heads/gitk gitk" would generate the gitk 
repository, with the addition of any changes to gitk made and committed in 
the git repository.

I think the only problem with this scheme would be that, if someone does a 
commit that changes both gitk and something else, the commit message might 
be a bit confusing in the gitk tree.

(I'm not sure, but this might also generate just the right thing for 
driver maintainers who want to distribute the latest version of their 
drivers as an out-of-tree module)

	-Daniel
*This .sig left intentionally blank*