On Tue, 23 Oct 2012, Jeff King wrote:
> On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote:
>
> > I agree that this is a common issue. Acked-by/Reviewed-by mails come
> > in after the fact that the patch has been committed to an immutable
> > (i.e no-rebas
On Tue, 23 Oct 2012, Al Viro wrote:
> On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote:
>
> > I fetched the series from your arch-tile branch and built it, and it works
> > fine. It looks good from my inspection:
> >
> > Acked-by: Chris Metcalf
>
> Thanks; Acked-by applied, branch
On Wed, 2005-07-06 at 21:48 -0700, Tony Luck wrote:
> Groan ... as well you should.
>
> My tree has re-appeared now. Thanks to whoever fixed it.
I noticed similar effects recently. Its related to the mirroring of
master.kernel.org to the public server. At some point you have only the
half of upd
Hi,
I can publish the stuff on monday from a university nearby.
---
total blob objects = 228384
total tree objects = 172507
total commit objects = 55877
The "empty" changesets which are noting merges are omitted at the
moment. Is it of interest to include them ??
It might also be interes
On Sat, 2005-04-16 at 12:15 -0700, Linus Torvalds wrote:
>
> On Sat, 16 Apr 2005, Thomas Gleixner wrote:
> >
> > For the export stuff its terrible slow. :(
>
> What kind of _strange_ scripting architecture is so fast that there's a
> difference between "c
On Sat, 2005-04-16 at 11:44 -0700, Linus Torvalds wrote:
> That level of abstraction ("we never look directly at the objects") is
> what allows us to change the object structure later. For example, we
> already changed the "commit" date thing once, and the tree object has
> obviously evolved a
On Sat, 2005-04-16 at 20:32 +0200, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 09:23:40PM CEST, I got a letter
> where Thomas Gleixner <[EMAIL PROTECTED]> told me that...
> > One remark on the tree blob storage format.
> > The binary storage of the sha1sum of
On Sat, 2005-04-16 at 10:04 -0700, Linus Torvalds wrote:
> So I'd _almost_ suggest just starting from a clean slate after all.
> Keeping the old history around, of course, but not necessarily putting it
> into git now. It would just force everybody who is getting used to git in
> the first plac
Hi folks,
I managed finally to export the complete kernel history into git format
The resulting number of objects is ~ 50
The required disk space is ~ 3.2 GiB
We also tracked the blob/tree/commit references in a SQL database. We
will post a SQL dump when the database is in a bit better shape.
9 matches
Mail list logo
