lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 15 Apr 2013 21:40:49 -0700
From:	Greg KH <greg@...ah.com>
To:	D M German <dmg@...c.ca>
Cc:	stable@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: helping with tracking commits across repos

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ