Re: helping with tracking commits across repos

[Greg KH <greg@kroah.com>]

On Mon, Apr 15, 2013 at 05:13:45PM -0700, D M German wrote:
> 
> 
>  Greg KH twisted the bytes to say:
> 
>  >> http://o.cs.uvic.ca:20810/perl/next.pl
> 
>  Greg> Yes, that's a great thing.  Maybe the ability to see the subject: line
>  Greg> of the commit somewhere easier than having to click through to the patch
>  Greg> would be nice, so we can just glance at the report and say, "Look at all
>  Greg> of the btrfs patches that showed up out of nowhere, what happened?"
> 
>  Greg> Oh, and if you could do it for a specific kernel release, not a date
>  Greg> range, that would be nice (i.e. report for 3.9-rc1, 3.8-rc1, 3.7-rc1,
>  Greg> etc.)
> 
> What would be the simplest approach to getting the date? I suspect that
> it can be done by doing some command line magic in Linus git repo.

You want to look at the commits from the last major release (i.e. 3.8)
to the -rc1 release, (i.e. 3.9-rc1).  You can't look at the dates,
that's not going to reflect when the patch landed in Linus's branch.

So a simple:
	git rev-list --no-merges v3.8..v3.9-rc1
will give you the commits needed.

As for storage issues, look at the -s option to 'git clone'.  If you
read the man page, it talks about the .git/objects/info/alternates file
you can use to save on diskspace.

Use Linus's repo as a full clone, and then all other git repo you pull
from, should have the alternates file pointing to Linus's tree.  That
way, only the commits that are not in Linus's tree will be in the
directory, the shared ones will not be duplicated.

You can do this today on your existing repos by creating the alternates
file, and then doing 'git gc' on the repo to clean out the duplicates.
That should save you a _lot_ of storage space.

And you should also be keeping only --bare repos, no need for the
checked out trees on your disks, you don't need them, right?

Hope this helps,

greg k-h