On 8 Dec 2007, Johannes Schindelin said:
> Hi,
>
> On Sat, 8 Dec 2007, J.C. Pizarro wrote:
>
>> On 2007/12/07, "Linus Torvalds" <[EMAIL PROTECTED]> wrote:
>>
>> > SHA1 is almost totally insignificant on x86. It hardly shows up. But
>> > we have a good optimized version there.
>>
>> If SHA1 is sl
On Thu, 2007-12-13 at 14:40 +, Rafael Espindola wrote:
> > Yes, everything, by default you only get the more modern branches/tags,
> > but it's all in there. If there is interest I can work with Bernardo
> > and get the rest publically exposed.
>
> I decided to give it a try, but could not fi
> Yes, everything, by default you only get the more modern branches/tags,
> but it's all in there. If there is interest I can work with Bernardo
> and get the rest publically exposed.
I decided to give it a try, but could not find the tuples branch. Is
it too hard to make gimple-tuples-branch and
On Mon, 10 Dec 2007, Gabriel Paubert wrote:
> On Fri, Dec 07, 2007 at 04:47:19PM -0800, Harvey Harrison wrote:
> > Some interesting stats from the highly packed gcc repo. The long chain
> > lengths very quickly tail off. Over 60% of the objects have a chain
> > length of 20 or less. If anyone w
From: David Miller <[EMAIL PROTECTED]>
Date: Fri, 07 Dec 2007 04:53:29 -0800 (PST)
> I should run oprofile...
While doing the initial object counting, most of the time is spent in
lookup_object(), memcmp() (via hashcmp()), and inflate(). I tried to
see if I could do some tricks on sparc with the
On Fri, Dec 07, 2007 at 04:47:19PM -0800, Harvey Harrison wrote:
> Some interesting stats from the highly packed gcc repo. The long chain
> lengths very quickly tail off. Over 60% of the objects have a chain
> length of 20 or less. If anyone wants the full list let me know. I
> also have includ
>
> Where did have you read this ? I missed that part.
>
> > When you object
> > that he's wasting your time, he'll start talking about freedom of speech.
> >
>
> Actually he never spoke like that (probably I missed that part too).
>
>
Read gcc mailing list archives, if you have a lot of time on
On Dec 8, 2007 8:53 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> Mr. Pizarro has endless ideas, and he'll give you some new ones every day.
That's true.
> He thinks that no one else knows any computer science, and he will attempt
> to teach you what he knows,
It's not the only one ;-) is in good
On Sat, 8 Dec 2007, J.C. Pizarro wrote:
> > 1. "Don't compress this repo but compact this uncompressed repo
> > using minimal spanning forest and deltas"
> > 2. "After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip
> > before
> > burning it to DVD for backup reasons or
Hi,
On Sat, 8 Dec 2007, J.C. Pizarro wrote:
> On 2007/12/07, "Linus Torvalds" <[EMAIL PROTECTED]> wrote:
>
> > SHA1 is almost totally insignificant on x86. It hardly shows up. But
> > we have a good optimized version there.
>
> If SHA1 is slow then why dont he contribute adding Haval160 (3 roun
Hi,
On Fri, 7 Dec 2007, Daniel Berlin wrote:
> On 12/7/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-12-07 at 14:14 -0800, Jakub Narebski wrote:
> >
> > > > >> Is SHA a significant portion of the compute during these
> > > > >> repacks? I should run oprofile...
> > > > > SHA1 is
On 2007/12/07, "Linus Torvalds" <[EMAIL PROTECTED]> wrote:
> On Fri, 7 Dec 2007, David Miller wrote:
> >
> > Also I could end up being performance limited by SHA, it's not very
> > well tuned on Sparc. It's been on my TODO list to code up the crypto
> > unit support for Niagara-2 in the kernel, th
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Fri, 7 Dec 2007 09:23:47 -0800 (PST)
>
>
> On Fri, 7 Dec 2007, David Miller wrote:
> >
> > Also I could end up being performance limited by SHA, it's not very
> > well tuned on Sparc. It's been on my TODO list to code up the crypto
> > unit suppor
Some interesting stats from the highly packed gcc repo. The long chain
lengths very quickly tail off. Over 60% of the objects have a chain
length of 20 or less. If anyone wants the full list let me know. I
also have included a few other interesting points, the git default
depth of 50, my initia
On 12/7/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-12-07 at 14:14 -0800, Jakub Narebski wrote:
>
> > > >> Is SHA a significant portion of the compute during these repacks?
> > > >> I should run oprofile...
> > > > SHA1 is almost totally insignificant on x86. It hardly shows up. But
On Fri, 2007-12-07 at 14:14 -0800, Jakub Narebski wrote:
> > >> Is SHA a significant portion of the compute during these repacks?
> > >> I should run oprofile...
> > > SHA1 is almost totally insignificant on x86. It hardly shows up. But
> > > we have a good optimized version there.
> > > zlib tend
On Dec 7, 2007, at 2:14 PM, Jakub Narebski wrote:
Giovanni Bajo <[EMAIL PROTECTED]> writes:
On 12/7/2007 6:23 PM, Linus Torvalds wrote:
Is SHA a significant portion of the compute during these repacks?
I should run oprofile...
SHA1 is almost totally insignificant on x86. It hardly shows up. Bu
Giovanni Bajo <[EMAIL PROTECTED]> writes:
> On 12/7/2007 6:23 PM, Linus Torvalds wrote:
>
> >> Is SHA a significant portion of the compute during these repacks?
> >> I should run oprofile...
> > SHA1 is almost totally insignificant on x86. It hardly shows up. But
> > we have a good optimized vers
On 12/7/2007 6:23 PM, Linus Torvalds wrote:
Is SHA a significant portion of the compute during these repacks?
I should run oprofile...
SHA1 is almost totally insignificant on x86. It hardly shows up. But we
have a good optimized version there.
zlib tends to be a lot more noticeable (especia
On Fri, 7 Dec 2007, Jon Smirl wrote:
> On 12/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Thu, 6 Dec 2007, Jon Smirl wrote:
> > > >
> > > > time git blame -C gcc/regclass.c > /dev/null
> > >
> > > [EMAIL PROTECTED]:/video/gcc$ time git blame -C gcc/regclass.c > /dev/null
On Fri, 7 Dec 2007, David Miller wrote:
>
> Also I could end up being performance limited by SHA, it's not very
> well tuned on Sparc. It's been on my TODO list to code up the crypto
> unit support for Niagara-2 in the kernel, then work with Herbert Xu on
> the userland interfaces to take advan
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Harvey Harrison wrote:
> >
> > I've updated the public mirror repo with the very-packed version.
>
> Side note: it might be interesting to compare timings for
> history-intensive stuff with and without this kind of very
On Thu, 6 Dec 2007, Harvey Harrison wrote:
>
> I've updated the public mirror repo with the very-packed version.
Side note: it might be interesting to compare timings for
history-intensive stuff with and without this kind of very-packed
situation.
The very density of a smaller pack-file migh
From: "Jon Smirl" <[EMAIL PROTECTED]>
Date: Fri, 7 Dec 2007 02:10:49 -0500
> On 12/7/07, Jeff King <[EMAIL PROTECTED]> wrote:
> > On Thu, Dec 06, 2007 at 07:31:21PM -0800, David Miller wrote:
> >
> > # and test multithreaded large depth/window repacking
> > cd test
> > git config pack.threads 4
>
On Thu, Dec 06, 2007 at 10:35:22AM -0800, Linus Torvalds wrote:
> > What is really disappointing is that we saved only about 20% of the
> > time. I didn't sit around watching the stages, but my guess is that we
> > spent a long time in the single threaded "writing objects" stage with a
> > thra
On Fri, Dec 07, 2007 at 01:50:47AM -0500, Jeff King wrote:
> Yes, but balanced by one thread running out of data way earlier than the
> other, and completing the task with only one CPU. I am doing a 4-thread
> test on a quad-CPU right now, and I will also try it with threads=1 and
> threads=6 for
On 12/7/07, Jeff King <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 06, 2007 at 07:31:21PM -0800, David Miller wrote:
>
> > > So it is about 5% bigger. What is really disappointing is that we saved
> > > only about 20% of the time. I didn't sit around watching the stages, but
> > > my guess is that we s
On 12/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Jon Smirl wrote:
> > >
> > > time git blame -C gcc/regclass.c > /dev/null
> >
> > [EMAIL PROTECTED]:/video/gcc$ time git blame -C gcc/regclass.c > /dev/null
> >
> > real1m21.967s
> > user1m21.329s
>
> We
On Thu, Dec 06, 2007 at 01:02:58PM -0500, Nicolas Pitre wrote:
> > What is really disappointing is that we saved
> > only about 20% of the time. I didn't sit around watching the stages, but
> > my guess is that we spent a long time in the single threaded "writing
> > objects" stage with a thrashin
On Thu, Dec 06, 2007 at 07:31:21PM -0800, David Miller wrote:
> > So it is about 5% bigger. What is really disappointing is that we saved
> > only about 20% of the time. I didn't sit around watching the stages, but
> > my guess is that we spent a long time in the single threaded "writing
> > objec
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, NightStrike wrote:
> >
> > No disrespect is meant by this reply. I am just curious (and I am
> > probably misunderstanding something).. Why remove all of the
> > documentation entirely? Wouldn't it be better to just
On Thu, 6 Dec 2007, Jon Smirl wrote:
> >
> > time git blame -C gcc/regclass.c > /dev/null
>
> [EMAIL PROTECTED]:/video/gcc$ time git blame -C gcc/regclass.c > /dev/null
>
> real1m21.967s
> user1m21.329s
Well, I was also hoping for a "compared to not-so-aggressive packing"
numb
On Thu, 6 Dec 2007, Jon Smirl wrote:
> I have a 4.8GB git process with 4GB of physical memory. Everything
> started slowing down a lot when the process got that big. Does git
> really need 4.8GB to repack? I could only keep 3.4GB resident. Luckily
> this happen at 95% completion. With 8GB of memor
From: Jeff King <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 12:39:47 -0500
> I tried the threaded repack with pack.threads = 3 on a dual-processor
> machine, and got:
>
> time git repack -a -d -f --window=250 --depth=250
>
> real309m59.849s
> user377m43.948s
> sys 8m23.319s
>
On Thu, 2007-12-06 at 13:04 -0500, Daniel Berlin wrote:
> On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > So the equivalent of "git gc --aggressive" - but done *properly* - is to
> > do (overnight) something like
> >
> > git repack -a -d --depth=250 --window=250
> >
> I gave th
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 6 Dec 2007, Jon Loeliger wrote:
>> I guess one question I posit is, would it be more accurate
>> to think of this as a "delta net" in a weighted graph rather
>> than a "delta chain"?
>
> It's certainly not a simple chain, it's more of a set of
On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > Well, that's possible with a window 25 times larger than the default.
> >
> > Why did it never use more than three cores?
>
> You have 648366 objects total, and only 647457 of them are subject to
> delta compression.
>
> With a window size
On Thu, 06 Dec 2007 23:26:07 +0100 David Kastrup wrote:
> Junio C Hamano <[EMAIL PROTECTED]> writes:
>
> > Junio C Hamano <[EMAIL PROTECTED]> writes:
> >
> >> Jon Loeliger <[EMAIL PROTECTED]> writes:
> >>
> >>> I'd like to learn more about that. Can someone point me to
> >>> either more document
On Thu, 6 Dec 2007, Jon Smirl wrote:
> On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > On Thu, 6 Dec 2007, Jon Smirl wrote:
> >
> > > On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > > > When I lasted looked at the code, the problem was in evenly dividing
> > > > > the work. I w
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Junio C Hamano <[EMAIL PROTECTED]> writes:
>
>> Jon Loeliger <[EMAIL PROTECTED]> writes:
>>
>>> I'd like to learn more about that. Can someone point me to
>>> either more documentation on it? In the absence of that,
>>> perhaps a pointer to the source
On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Dec 2007, Jon Smirl wrote:
>
> > On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > > When I lasted looked at the code, the problem was in evenly dividing
> > > > the work. I was using a four core machine and most of the time
On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Dec 2007, Jon Smirl wrote:
>
> > On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > > When I lasted looked at the code, the problem was in evenly dividing
> > > > the work. I was using a four core machine and most of the time
On Thu, 6 Dec 2007, Jon Smirl wrote:
> On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > When I lasted looked at the code, the problem was in evenly dividing
> > > the work. I was using a four core machine and most of the time one
> > > core would end up with 3-5x the work of the lightest
On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > When I lasted looked at the code, the problem was in evenly dividing
> > the work. I was using a four core machine and most of the time one
> > core would end up with 3-5x the work of the lightest loaded core.
> > Setting pack.threads up to 2
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Jon Loeliger <[EMAIL PROTECTED]> writes:
>
>> I'd like to learn more about that. Can someone point me to
>> either more documentation on it? In the absence of that,
>> perhaps a pointer to the source code that implements it?
>
> See Documentation/tech
On 12/6/07, Andrey Belevantsev <[EMAIL PROTECTED]> wrote:
> Vincent Lefevre wrote:
> > It's surprising that you don't mention svk, which is based on top
> > of Subversion[*]. Has anyone tried? Is there any problem with it?
> I must agree with Ismail's reply here. We have used svk for our
> interna
On 2007/12/6, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote:
> For multicores CPUs, don't divide the work in threads.
> To divide the work in processes!
>
> Tips, tricks and hacks: to use fork, exec, pipes and another IPC mechanisms
> like
> mutexes, shared memory's IPC, file locks, pipes, semaphores,
Vincent Lefevre wrote:
It's surprising that you don't mention svk, which is based on top
of Subversion[*]. Has anyone tried? Is there any problem with it?
I must agree with Ismail's reply here. We have used svk for our
internal development for about two years, for the reason of easy
mirroring
Jon Loeliger <[EMAIL PROTECTED]> writes:
> On Thu, 2007-12-06 at 00:09, Linus Torvalds wrote:
>
>> Git also does delta-chains, but it does them a lot more "loosely". There
>> is no fixed entity. Delta's are generated against any random other version
>> that git deems to be a good delta candidate
On Thu, 6 Dec 2007, Jon Loeliger wrote:
>
> On Thu, 2007-12-06 at 00:09, Linus Torvalds wrote:
> > Git also does delta-chains, but it does them a lot more "loosely". There
> > is no fixed entity. Delta's are generated against any random other version
> > that git deems to be a good delta candid
Thursday 06 December 2007 21:28:59 Vincent Lefevre yazmıştı:
> On 2007-12-06 10:15:17 -0800, Ian Lance Taylor wrote:
> > Distributed version systems like git or Mercurial have some advantages
> > over Subversion.
>
> It's surprising that you don't mention svk, which is based on top
> of Subversion[
On 2007-12-06 10:15:17 -0800, Ian Lance Taylor wrote:
> Distributed version systems like git or Mercurial have some advantages
> over Subversion.
It's surprising that you don't mention svk, which is based on top
of Subversion[*]. Has anyone tried? Is there any problem with it?
[*] You have curren
On 2007/12/06, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > On Thu, 6 Dec 2007, Jeff King wrote:
> > >
> > > What is really disappointing is that we saved only about 20% of the
> > > time. I didn't sit around watching the stages, but my guess is
On Thu, 2007-12-06 at 00:09, Linus Torvalds wrote:
> Git also does delta-chains, but it does them a lot more "loosely". There
> is no fixed entity. Delta's are generated against any random other version
> that git deems to be a good delta candidate (with various fairly
> successful heursitics),
On Thu, 6 Dec 2007, Jon Smirl wrote:
> On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Thu, 6 Dec 2007, Jeff King wrote:
> > >
> > > What is really disappointing is that we saved only about 20% of the
> > > time. I didn't sit around watching the stages, but my guess is that we
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Jeff King wrote:
> >
> > What is really disappointing is that we saved only about 20% of the
> > time. I didn't sit around watching the stages, but my guess is that we
> > spent a long time in the single threaded "writi
On Thu, 6 Dec 2007, NightStrike wrote:
>
> No disrespect is meant by this reply. I am just curious (and I am
> probably misunderstanding something).. Why remove all of the
> documentation entirely? Wouldn't it be better to just document it
> more thoroughly?
Well, part of it is that I don't
On Thu, 6 Dec 2007, Jeff King wrote:
>
> What is really disappointing is that we saved only about 20% of the
> time. I didn't sit around watching the stages, but my guess is that we
> spent a long time in the single threaded "writing objects" stage with a
> thrashing delta cache.
I don't thi
On Thu, 6 Dec 2007, Daniel Berlin wrote:
>
> I worked on Monotone and other systems that use object stores. for a
> little while :) In particular, I believe GIT's original object store was
> based on Monotone, IIRC.
Yes and no.
Monotone does what git does for the blobs. But there is a big di
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Daniel Berlin wrote:
> >
> > Actually, it turns out that git-gc --aggressive does this dumb thing
> > to pack files sometimes regardless of whether you converted from an
> > SVN repo or not.
> I'll send a patch to Junio
NightStrike <[EMAIL PROTECTED]> writes:
> On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > As I said, maybe i'll look at git in another year or so.
> > But i'm certainly going to ignore all the "git is so great, we should
> > move gcc to it" people until it works better, while i am much m
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Daniel Berlin wrote:
> >
> > Actually, it turns out that git-gc --aggressive does this dumb thing
> > to pack files sometimes regardless of whether you converted from an
> > SVN repo or not.
>
> Absolutely. git --aggres
On Thu, 6 Dec 2007, Jeff King wrote:
> On Thu, Dec 06, 2007 at 09:18:39AM -0500, Nicolas Pitre wrote:
>
> > > The downside is that the threading partitions the object space, so the
> > > resulting size is not necessarily as small (but I don't know that
> > > anybody has done testing on large repo
On Thu, Dec 06, 2007 at 09:18:39AM -0500, Nicolas Pitre wrote:
> > The downside is that the threading partitions the object space, so the
> > resulting size is not necessarily as small (but I don't know that
> > anybody has done testing on large repos to find out how large the
> > difference is).
On Thu, 6 Dec 2007, Jeff King wrote:
> On Thu, Dec 06, 2007 at 01:47:54AM -0500, Jon Smirl wrote:
>
> > The key to converting repositories of this size is RAM. 4GB minimum,
> > more would be better. git-repack is not multi-threaded. There were a
> > few attempts at making it multi-threaded but no
On Wed, 5 Dec 2007, Harvey Harrison wrote:
>
> > git repack -a -d --depth=250 --window=250
> >
>
> Since I have the whole gcc repo locally I'll give this a shot overnight
> just to see what can be done at the extreme end or things.
Don't forget to add -f as well.
Nicolas
On Thu, 2007-12-06 at 10:52 +0100, Andreas Schwab wrote:
> Harvey Harrison <[EMAIL PROTECTED]> writes:
>
> > git svn does accept a mailmap at import time with the same format as the
> > cvs importer I think. But for someone that just wants a repo to check
> > out this was easiest. I'd be willin
Thursday 06 December 2007 13:57:06 Johannes Schindelin yazmıştı:
[...]
> So I fully expect an issue like Daniel's to be resolved in a matter of
> minutes on the git list, if the OP gives us a chance. If we are not even
> Cc'ed, you are completely right, she or he probably does not want the
> issue
Hi,
On Wed, 5 Dec 2007, David Miller wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 21:41:19 -0500
>
> > It is true I gave up quickly, but this is mainly because i don't like
> > to fight with my tools.
> >
> > I am quite fine with a distributed workflow, I now use 8
Harvey Harrison <[EMAIL PROTECTED]> writes:
> git svn does accept a mailmap at import time with the same format as the
> cvs importer I think. But for someone that just wants a repo to check
> out this was easiest. I'd be willing to spend the time to do a nicer
> job if there was any interest fr
On Wed, Dec 05, 2007 at 11:49:21PM -0800, Harvey Harrison wrote:
git repack -a -d --depth=250 --window=250
Since I have the whole gcc repo locally I'll give this a shot overnight
just to see what can be done at the extreme end or things.
When I tried this on a very large repo, at l
> git repack -a -d --depth=250 --window=250
>
Since I have the whole gcc repo locally I'll give this a shot overnight
just to see what can be done at the extreme end or things.
Harvey
On Thu, Dec 06, 2007 at 01:47:54AM -0500, Jon Smirl wrote:
> The key to converting repositories of this size is RAM. 4GB minimum,
> more would be better. git-repack is not multi-threaded. There were a
> few attempts at making it multi-threaded but none were too successful.
> If I remember right, w
On 12/6/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > While you won't get the git svn metadata if you clone the infradead
> > repo, it can be recreated on the fly by git svn if you want to start
> > commiting directly to gcc svn.
> >
> I will give this a try :)
Back when I was working on the Mo
On Thu, 6 Dec 2007, Daniel Berlin wrote:
>
> Actually, it turns out that git-gc --aggressive does this dumb thing
> to pack files sometimes regardless of whether you converted from an
> SVN repo or not.
Absolutely. git --aggressive is mostly dumb. It's really only useful for
the case of "I kno
> While you won't get the git svn metadata if you clone the infradead
> repo, it can be recreated on the fly by git svn if you want to start
> commiting directly to gcc svn.
>
I will give this a try :)
On Thu, 2007-12-06 at 00:11 -0500, Daniel Berlin wrote:
> On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Daniel Berlin" <[EMAIL PROTECTED]>
> > Date: Wed, 5 Dec 2007 23:32:52 -0500
> >
> > > On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > > > From: "Daniel Berlin" <[EMAIL PR
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 23:32:52 -0500
>
> > On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > > From: "Daniel Berlin" <[EMAIL PROTECTED]>
> > > Date: Wed, 5 Dec 2007 22:47:01 -0500
> > >
> > > > T
On Wed, 2007-12-05 at 20:54 -0800, Linus Torvalds wrote:
>
> On Wed, 5 Dec 2007, Harvey Harrison wrote:
> >
> > If anyone recalls my report was something along the lines of
> > git gc --aggressive explodes pack size.
> [ By default, for example, "git svn clone/fetch" seems to create those
> h
On Wed, 5 Dec 2007, Harvey Harrison wrote:
>
> If anyone recalls my report was something along the lines of
> git gc --aggressive explodes pack size.
Yes, --aggressive is generally a bad idea. I think we should remove it or
at least fix it. It doesn't do what the name implies, because it actua
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 23:32:52 -0500
> On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Daniel Berlin" <[EMAIL PROTECTED]>
> > Date: Wed, 5 Dec 2007 22:47:01 -0500
> >
> > > The size is clearly not just svn data, it's in the git pack itself.
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 22:47:01 -0500
>
> > The size is clearly not just svn data, it's in the git pack itself.
>
> And other users have shown much smaller metadata from a GIT import,
> and yes those ar
On Wed, 2007-12-05 at 20:20 -0800, David Miller wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 22:47:01 -0500
>
> > The size is clearly not just svn data, it's in the git pack itself.
>
> And other users have shown much smaller metadata from a GIT import,
> and yes th
I fought with this a few months ago when I did my own clone of gcc svn.
My bad for only discussing this on #git at the time. Should have put
this to the list as well.
If anyone recalls my report was something along the lines of
git gc --aggressive explodes pack size.
git repack -a -d --depth=100
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 22:47:01 -0500
> The size is clearly not just svn data, it's in the git pack itself.
And other users have shown much smaller metadata from a GIT import,
and yes those are including all of the repository history and branches
not just
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 21:41:19 -0500
>
> > It is true I gave up quickly, but this is mainly because i don't like
> > to fight with my tools.
> > I am quite fine with a distributed workflow, I now use 8
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 21:41:19 -0500
> It is true I gave up quickly, but this is mainly because i don't like
> to fight with my tools.
> I am quite fine with a distributed workflow, I now use 8 or so gcc
> branches in mercurial (auto synced from svn) and m
ure there are magic options, magic command lines, etc, i could
> > use to make it smaller.
> >
> > I'm sure if i spent the next few weeks fucking around with git, it may
> > even be usable!
> >
> > But given that git is harder to use, requires manual r
git, it may
> even be usable!
>
> But given that git is harder to use, requires manual repacking to get
> any kind of sane space usage, and is 3x bigger anyway, i don't see any
> advantage to continuing to experiment with git and gcc.
I would really appreciate it if you would s
On Dec 5, 2007 1:40 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>
> > Out of curiosity, how much of that is the .git/svn directory? This is
> > where git-svn-specific data is stored. It is *very* inefficient, at
> > least for the 1.5.2.5 version I'm using.
> >
>
> I was only counting the space i
On Thu, 2007-12-06 at 00:34 +0100, Andreas Schwab wrote:
> Harvey Harrison <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2007-12-05 at 21:23 +0100, Samuel Tardieu wrote:
> >> > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
> >>
> >> Daniel> So I tried a full history conversion using git-s
Harvey Harrison <[EMAIL PROTECTED]> writes:
> On Wed, 2007-12-05 at 21:23 +0100, Samuel Tardieu wrote:
>> > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
>>
>> Daniel> So I tried a full history conversion using git-svn of the gcc
>> Daniel> repository (IE every trunk revision from 1-H
> But given that git is harder to use, requires manual repacking to get
> any kind of sane space usage, and is 3x bigger anyway, i don't see any
> advantage to continuing to experiment with git and gcc.
>
> I already have two way sync with hg.
> Maybe someday when git is more usab
On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> As I said, maybe i'll look at git in another year or so.
> But i'm certainly going to ignore all the "git is so great, we should
> move gcc to it" people until it works better, while i am much more
> inclined to believe the "hg is so great, we
On Wed, 2007-12-05 at 21:23 +0100, Samuel Tardieu wrote:
> > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> Daniel> So I tried a full history conversion using git-svn of the gcc
> Daniel> repository (IE every trunk revision from 1-HEAD as of
> Daniel> yesterday) The git-svn import w
On 12/5/07, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
> > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> Daniel> So I tried a full history conversion using git-svn of the gcc
> Daniel> repository (IE every trunk revision from 1-HEAD as of
> Daniel> yesterday) The git-svn import was d
On 12/5/07, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On Dec 5, 2007 11:08 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > So I tried a full history conversion using git-svn of the gcc
> > repository (IE every trunk revision from 1-HEAD as of yesterday)
> > The git-svn import was done using repacks
> "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
Daniel> So I tried a full history conversion using git-svn of the gcc
Daniel> repository (IE every trunk revision from 1-HEAD as of
Daniel> yesterday) The git-svn import was done using repacks every
Daniel> 1000 revisions. After it finis
On Dec 5, 2007 11:08 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc -
Wednesday 05 December 2007 21:08:41 Daniel Berlin yazmıştı:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc --aggre
1 - 100 of 104 matches
Mail list logo
