* Re: Linus kernel tree corrupt?
From: H. Peter Anvin @ 2005-07-09 18:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Russell King, Tony Luck, Jon Smirl, git
In-Reply-To: <20050709115530.GC26343@pasky.ji.cz>
Petr Baudis wrote:
>
> Yes, please do. I deprecated rsync a day before Linus "broke" http-pull.
> It's un-deprecated again for now in the latest Cogito.
>
Presumably for packed repos you want to drop the --ignore-existing
--whole-file options I assume?
Also, pulling with cogito-0.12:
cg-clone -s
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
I still get:
receiving file list ... done
master
sent 147 bytes received 863 bytes 2020.00 bytes/sec
total size is 41 speedup is 0.04
receiving file list ... done
progress: 1929 objects, 5796451 bytes, 100% done
pack/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.idx
pack/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack
sent 42599 bytes received 73373124 bytes 451789.06 bytes/sec
total size is 73178114 speedup is 1.00
receiving file list ... done
v2.6.11
v2.6.11-tree
v2.6.12
v2.6.12-rc2
v2.6.12-rc3
v2.6.12-rc4
v2.6.12-rc5
v2.6.12-rc6
v2.6.13-rc1
v2.6.13-rc2
sent 339 bytes received 1802 bytes 4282.00 bytes/sec
total size is 410 speedup is 0.19
Missing object of tag v2.6.11... different source (obsolete tag?)
Missing object of tag v2.6.11-tree... different source (obsolete tag?)
Missing object of tag v2.6.12... different source (obsolete tag?)
Missing object of tag v2.6.12-rc2... different source (obsolete tag?)
Missing object of tag v2.6.12-rc3... different source (obsolete tag?)
Missing object of tag v2.6.12-rc4... different source (obsolete tag?)
Missing object of tag v2.6.12-rc5... different source (obsolete tag?)
Missing object of tag v2.6.12-rc6... different source (obsolete tag?)
Missing object of tag v2.6.13-rc1... different source (obsolete tag?)
Missing object of tag v2.6.13-rc2... different source (obsolete tag?)
New branch: 0109fd37046de64e8459f8c4f4706df9ac7cc82c
Cloned (origin
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
available as branch "origin")
Cloned to ./ (origin
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
available as branch "origin")
Is the "missing objects" thing spurious?
-hpa
^ permalink raw reply
* Re: cogito Mac OS X compatibility
From: Bryan Larsen @ 2005-07-09 18:38 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20050709165028.GY18608MdfPADPa@garage.linux.student.kuleuven.ac.be>
> Sounds like you're missing "stat" from coreutils.
>
> skimo
>
Thanks. I've got it working to the point where it passes "make test"
now. All I had to do was install coreutils and findutils from
darwinports, and then make gcp, gstat and gnuxargs available under their
standard names.
Do the BSD's or Solaris have the same problem? Last time I used them
they didn't have the gnu options available on their standard utils, but
that was ages ago. If current BSD's have the problem, it might be worth
expending some effort to make cogito more portable. If it's only OS X...
Bryan
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Matthias Urlichs @ 2005-07-09 21:04 UTC (permalink / raw)
To: git
In-Reply-To: <20050709011119.GA10981@buici.com>
Hi, Marc Singer wrote:
> Yet, patch does apply. [...]
> patching file drivers/ide/ide-io.c
> Hunk #1 succeeded at 96 with fuzz 2 (offset -33 lines).
git-apply cowardly (but sensibly) refuses to apply patches with fuzz
(i.e., ignoring some supplied context lines).
Fuzz indicates problems.
I'd suggest that you apply the patch to whatever version it is based on...
> o Is there a way to force git to apply and safe the rejects?
Well, you can use "patch -p1 ..." directly, and manually add the files it
created to the object cache. Personally I wouldn't, if at all possible.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I couldn't remember things until I took that Sam Carnegie course.
-- Bill Peterson, former Houston Oiler football coach
^ permalink raw reply
* Re: [PATCH] rev-list: add "--full-objects" flag.
From: Eric W. Biederman @ 2005-07-09 21:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507071928220.25104@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 7 Jul 2005, Junio C Hamano wrote:
>>
>> However it does not automatically mean that the avenue I have
>> been pursuing would not work; the server side preparation needs
>> to be a bit more careful than what I sent, which unconditionally
>> runs "prune-packed". It instead should leave the files that
>> "--whole-trees" would have packed as plain SHA1 files, so that
>> the bulk is obtained by statically generated packs and the rest
>> can be handled in the commit-chain walker as before.
> The "fetch one object, parse it, fetch the next one, parse that.."
> approach is just horrible.
Agreed. That does not cover up latency at all and depending on the
parsing cost can potentially even keep you from having anything on
your network connection for a noticeable amount of time.
> I ended up preferring the "rsync" thing even though rsync sucked badly on
> big object stores too, if only because when rsync got working, it at least
> nicely pipelined the transfers, and would transfer things ten times faster
> than git-ssh-pull did (maybe I'm exaggerating, but I don't think so, it
> really felt that way).
This feels to me like an implementation issue (no pipelining) rather
than a design issue (pipelining is impossible).
> And the thing is, if you purely follow one tree (which is likely the
> common case for a lot of users), then you are actually always likely
> better off with the "mirror it" model. Which is _not_ a good model for
> developers (for example, me rsync'ing from Jeff's kernel repository always
> got me hundreds of useless objects), but it's fine for somebody who
> actually just wants to track somebody else.
I assume the problem with the mirror it model was simply there were
to many objects?
> And then you really can use just rsync or wget or ncftpget or anything
> else that has a "fetch recursively, optimizing existing objects" mode.
Sane. But with an intelligent fetcher and a little extra information
a dumb server should still be able to not fetch branches we care
nothing about. I think that extra information is simply commit
object graph and which packs those commit objects are in. I assume
the commit graph information will be fairly modest.
Once you have that extra information you can generate incremental
packs whenever you upload to the server, and you can make the
incremental packs per branch.
That should allow an dumb fetcher to look at the list of commits
and just fetch those packs it cares about, and since it only has
to look one place first it should be fairly sane.
The core idea is that if the dumb-server-preparation can anticipate
common access patterns (mirror a branch) and give enough information
so that can be done cheaply and pipelined I don't expect it to be much
worse than an intelligent fetcher.
The current intelligent fetch currently has a problem that it cannot
be used to bootstrap a repository. If you don't have an ancestor
of what you are fetching you can't fetch it.
Eric
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Russell King @ 2005-07-09 21:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tony Luck, Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507071720330.25104@g5.osdl.org>
On Thu, Jul 07, 2005 at 05:23:26PM -0700, Linus Torvalds wrote:
> On Thu, 7 Jul 2005, Tony Luck wrote:
> > This is what happens ("linus" is a local branch just pulled from kernel.org,
> > so it just contains one pack file and its index).
> >
> > $ cg-update linus
> > `/home/aegl/GIT/linus/.git/refs/heads/master' -> `.git/refs/heads/linus'
> > does not exist /home/aegl/GIT/linus/.git/objects/04/3d051615aa5da09a7e44f1edbb69
> > 798458e067
> > Cannot obtain needed object 043d051615aa5da09a7e44f1edbb69798458e067
> > while processing commit 0000000000000000000000000000000000000000.
> > cg-pull: objects pull failed
>
> Ok. The immediate fix is to just unpack the pack:
>
> mv .git/objects/pack/* .git/
> for i in .git/*.pack; do git-unpack-objects < $i; done
>
> (or similar - the above is untested, but I think it should be obvious
> enough what I'm trying to do).
This is evil on the bandwidth, since you'll keep refetching the packed
object (64MB of it) over and over.
However, I've tried the above, and I get:
$ mv .git/objects/pack/* .git/
$ for i in .git/*.pack; do git-unpack-objects < $i; done
Unpacking 55435 objects
fatal: inflate returned -3
so it seems that the pack is corrupt... or something.
$ md5sum .git/*.pack
2be38f2947b99bcd088c1930122aadec .git/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack
and git-fsck-cache produces lots and lots of:
dangling tree fae688b62db0b553aae0bf17f0f70e93819dec2b
broken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347
to blob 008e19210e66f01fbaef1aba30243850766b8b12
broken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347
to blob edae09a4b021e353ab4fbba756e31492fbb8fd2e
broken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347
to blob d098b3ba35384fb912989348fd6da59820711ca4
... etc ...
--
Russell King
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Russell King @ 2005-07-09 22:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tony Luck, Petr Baudis, Junio C Hamano, git
In-Reply-To: <20050709225818.A31045@flint.arm.linux.org.uk>
On Sat, Jul 09, 2005 at 10:58:18PM +0100, Russell King wrote:
> On Thu, Jul 07, 2005 at 05:23:26PM -0700, Linus Torvalds wrote:
> > On Thu, 7 Jul 2005, Tony Luck wrote:
> > > This is what happens ("linus" is a local branch just pulled from kernel.org,
> > > so it just contains one pack file and its index).
> > >
> > > $ cg-update linus
> > > `/home/aegl/GIT/linus/.git/refs/heads/master' -> `.git/refs/heads/linus'
> > > does not exist /home/aegl/GIT/linus/.git/objects/04/3d051615aa5da09a7e44f1edbb69
> > > 798458e067
> > > Cannot obtain needed object 043d051615aa5da09a7e44f1edbb69798458e067
> > > while processing commit 0000000000000000000000000000000000000000.
> > > cg-pull: objects pull failed
> >
> > Ok. The immediate fix is to just unpack the pack:
> >
> > mv .git/objects/pack/* .git/
> > for i in .git/*.pack; do git-unpack-objects < $i; done
> >
> > (or similar - the above is untested, but I think it should be obvious
> > enough what I'm trying to do).
>
> This is evil on the bandwidth, since you'll keep refetching the packed
> object (64MB of it) over and over.
>
> However, I've tried the above, and I get:
>
> $ mv .git/objects/pack/* .git/
> $ for i in .git/*.pack; do git-unpack-objects < $i; done
> Unpacking 55435 objects
> fatal: inflate returned -3
>
> so it seems that the pack is corrupt... or something.
>
> $ md5sum .git/*.pack
> 2be38f2947b99bcd088c1930122aadec .git/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack
>
> and git-fsck-cache produces lots and lots of:
>
> dangling tree fae688b62db0b553aae0bf17f0f70e93819dec2b
> broken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347
> to blob 008e19210e66f01fbaef1aba30243850766b8b12
> broken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347
> to blob edae09a4b021e353ab4fbba756e31492fbb8fd2e
> broken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347
> to blob d098b3ba35384fb912989348fd6da59820711ca4
> ... etc ...
Additional information: x86 box, running FC2, cogito 0.12 built from
the src.rpm on kernel.org. Lots of disk space (blocks + inodes)
remaining.
Pretty please can we stop breaking rmk's git/cogito/repos/scripts ?
--
Russell King
^ permalink raw reply
* Re: What broke snapshots now?
From: David Woodhouse @ 2005-07-09 23:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507090908490.17536@g5.osdl.org>
On Sat, 2005-07-09 at 09:15 -0700, Linus Torvalds wrote:
> Yes, looks that way. Except it's not "git on master.kernel.org", it's "git
> in your home directory", I suspect. I expressly held off packing the
> kernel repo until git had been updated on kernel.org.
Doh. I thought I'd already done that, but in fact that was for the
scripts which feed the mailing list, while the snapshot script kept
using my copy. I've moved it out of the way now; sorry for the noise.
--
dwmw2
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Junio C Hamano @ 2005-07-09 23:46 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Tony Luck, Petr Baudis, git
In-Reply-To: <20050709232955.B31045@flint.arm.linux.org.uk>
>>>>> "RK" == Russell King <rmk@arm.linux.org.uk> writes:
>> $ mv .git/objects/pack/* .git/
>> $ for i in .git/*.pack; do git-unpack-objects < $i; done
>> Unpacking 55435 objects
>> fatal: inflate returned -3
>>
>> so it seems that the pack is corrupt... or something.
>>
>> $ md5sum .git/*.pack
>> 2be38f2947b99bcd088c1930122aadec .git/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack
RK> Additional information: x86 box, running FC2, cogito 0.12 built from
RK> the src.rpm on kernel.org. Lots of disk space (blocks + inodes)
RK> remaining.
Hmph, I am worried about that inflate() failure. An x86 box,
running Debian sarge, vanilla git without Cogito built from
Linus tip. From here, it does not look like the pack corruption
to me; unless you broke md5sum and found a collission, that is.
: siamese; type git-unpack-objects
git-unpack-objects is /home/junio/bin/Linux/git-unpack-objects
: siamese; ldd /home/junio/bin/Linux/git-unpack-objects
libz.so.1 => /usr/lib/libz.so.1 (0xb7f8e000)
libcrypto.so.0.9.7 =>
/usr/lib/i686/cmov/libcrypto.so.0.9.7 (0xb7e8e000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7d59000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7d56000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fad000)
: siamese; cd /opt/packrat/playpen/public/in-place/git/linux-2.6/
: siamese; md5sum .git/objects/pack/pack-*.pack
2be38f2947b99bcd088c1930122aadec .git/objects/pack/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack
: siamese; cd ..
: siamese; mkdir junk
: siamese; cd junk
: siamese; git-init-db
defaulting to local storage area
: siamese; git-unpack-objects <../linux-2.6/.git/objects/pack/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack
Unpacking 55435 objects 100% (55434/55435) done
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Linus Torvalds @ 2005-07-10 5:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Russell King, Tony Luck, Petr Baudis, git
In-Reply-To: <7vpstrv8z6.fsf@assigned-by-dhcp.cox.net>
On Sat, 9 Jul 2005, Junio C Hamano wrote:
>
> >>>>> "RK" == Russell King <rmk@arm.linux.org.uk> writes:
>
> >> $ mv .git/objects/pack/* .git/
> >> $ for i in .git/*.pack; do git-unpack-objects < $i; done
> >> Unpacking 55435 objects
> >> fatal: inflate returned -3
Ahh, damn.
> >> so it seems that the pack is corrupt... or something.
No, I htink you're using cogito-0.12, and I fixed this one-liner that
didn't make it into cogito:
diff-tree 291ec0f2d2ce65e5ccb876b46d6468af49ddb82e (from 72347a233e6f3c176059a28f0817de6654ef29c7)
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Tue Jul 5 17:06:09 2005 -0700
Don't special-case a zero-sized compression.
zlib actually writes a header for that case, and while ignoring that
header will get us the right data, it will also end up messing up our
stream position. So we actually want zlib to "uncompress" even an empty
object.
diff --git a/unpack-objects.c b/unpack-objects.c
--- a/unpack-objects.c
+++ b/unpack-objects.c
@@ -55,8 +55,6 @@ static void *get_data(unsigned long size
z_stream stream;
void *buf = xmalloc(size);
- if (!size)
- return buf;
memset(&stream, 0, sizeof(stream));
stream.next_out = buf;
(well, I guess it's a two-liner.).
What happens is that there's one zero-sized blob in the kernel archive
history, and when we pack it, we pack it as a 8-byte "compressed" thing
(hey, zlib has a header, that's normal), but when we unpack it, because we
notice that the result is zero, we'd just skip the zlib header.
Which was wrong, because now the _next_ object will try to unpack at the
wrong offset, and that explains why you get -3 ("bad data").
Linus
^ permalink raw reply
* Re: [PATCH] rev-list: add "--full-objects" flag.
From: Linus Torvalds @ 2005-07-10 5:11 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1pstrr8k1.fsf@ebiederm.dsl.xmission.com>
On Sat, 9 Jul 2005, Eric W. Biederman wrote:
>
> I assume the problem with the mirror it model was simply there were
> to many objects?
Yes.
> > And then you really can use just rsync or wget or ncftpget or anything
> > else that has a "fetch recursively, optimizing existing objects" mode.
>
> Sane. But with an intelligent fetcher and a little extra information a
> dumb server should still be able to not fetch branches we care nothing
> about. I think that extra information is simply commit object graph and
> which packs those commit objects are in. I assume the commit graph
> information will be fairly modest.
Well, what I'd hope for is actually that eventually "webgit" will have
some machine-parseable sub-tree, and then you can have this kind of thing
generated automatically.
But a _truly_ dumb server (ie one with no CGI at all, just "raw data", you
really end up with just effectively rsyncing it. Yes, you could create a
new "commit index file" every time you push, and maybe it's worth it, but
on the other hand, what's wrong with just rsyncing it all and parsing it
locally instead?
People who use it for major development would all try to get the smart
client, even if it's "just" some webgit extension thing..
Dumb servers work, they just won't do any selective stuff. Big deal.
That's why they are dumb.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Linus Torvalds @ 2005-07-10 5:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Russell King, Tony Luck, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0507092158290.17536@g5.osdl.org>
On Sat, 9 Jul 2005, Linus Torvalds wrote:
>
> No, I htink you're using cogito-0.12, and I fixed this one-liner that
> didn't make it into cogito:
Btw, this will only affect unpacking. The packed objects should be fine,
and you'll never see this if you keep the index file around and have the
pack in .git/objects/pack, because then git won't ever do the "streaming"
thing, it will look up exactly where the object is using the index, and it
doesn't matter that it doesn't look at the compressed data of a zero-sized
object.
So cogito isn't terminally broken, it just can't do the streaming unpack.
And as Russell points out, unpacking the packs after downloading them is
actually the wrong thing to do, because you break the rsync'ness of your
archive, so you'll keep on downloading the pack-files over and over again.
So you can fix this by getting the current git release, but you probably
shouldn't even care. Just use the pack-files as pack-files instead, and
enjoy the higher performance and lower disk use ;).
Linus
^ permalink raw reply
* Re: [PATCH] rev-list: add "--full-objects" flag.
From: Junio C Hamano @ 2005-07-10 6:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, git
In-Reply-To: <Pine.LNX.4.58.0507092206480.17536@g5.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
>> On Sat, 9 Jul 2005, Eric W. Biederman wrote:
>> I assume the commit graph information will be fairly modest.
That is true. My experience from the one I have been cooking,
Gitified 2.4.0->2.6.12-rc2 BKCVS export results in a bit shy of
600KB commit ancestry information. The full development trail
for that repository contains 370152 objects among which 28237
are commits; when packed into one pack-idx pair, it is around
a 170MB .pack with a 9MB .idx file.
LT> But a _truly_ dumb server (ie one with no CGI at all, just "raw data", you
LT> really end up with just effectively rsyncing it. Yes, you could create a
LT> new "commit index file" every time you push, and maybe it's worth it, but
LT> on the other hand, what's wrong with just rsyncing it all and parsing it
LT> locally instead?
Nothing, and you convinced me to drop the one I have been
cooking. Maybe its time to either change git-fetch-script to
use wget -r for http transport for objects part, perhaps?
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Russell King @ 2005-07-10 6:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Tony Luck, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0507092211470.17536@g5.osdl.org>
On Sat, Jul 09, 2005 at 10:15:41PM -0700, Linus Torvalds wrote:
> So you can fix this by getting the current git release, but you probably
> shouldn't even care. Just use the pack-files as pack-files instead, and
> enjoy the higher performance and lower disk use ;).
I would if I could, but my workflow involves having an untouched local
copy of your tree and several trees for each area.
This involves updates using relative paths, and as has already been
found elsewhere, this (with cogito 0.12) doesn't work with packed
objects yet.
--
Russell King
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Junio C Hamano @ 2005-07-10 7:15 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Tony Luck, Petr Baudis, git
In-Reply-To: <20050710075548.A11765@flint.arm.linux.org.uk>
>>>>> "RK" == Russell King <rmk@arm.linux.org.uk> writes:
RK> I would if I could, but my workflow involves having an untouched local
RK> copy of your tree and several trees for each area.
RK> This involves updates using relative paths, and as has already been
RK> found elsewhere, this (with cogito 0.12) doesn't work with packed
RK> objects yet.
As a workaround until Cogito gets updated, would it help to have
the environment variable GIT_ALTERNATE_OBJECT_DIRECTORIES
pointing at the untouched copy of Linus tree's .git/objects/
directory? All your other trees would find the objects in your
copied-Linus tree (including packed one) available to them
already and hopefully pull breakage does not even have to touch
those objects.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Russell King @ 2005-07-10 8:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050709225818.A31045@flint.arm.linux.org.uk>
On Sat, Jul 09, 2005 at 10:58:18PM +0100, Russell King wrote:
> $ mv .git/objects/pack/* .git/
> $ for i in .git/*.pack; do git-unpack-objects < $i; done
> Unpacking 55435 objects
> fatal: inflate returned -3
This morning's cg-update gave these new errors:
receiving file list ... done
wrote 86 bytes read 192 bytes 556.00 bytes/sec
total size is 410 speedup is 1.47
Missing object of tag v2.6.11... different source (obsolete tag?)
Missing object of tag v2.6.11-tree... different source (obsolete tag?)
Missing object of tag v2.6.12... different source (obsolete tag?)
Missing object of tag v2.6.12-rc2... different source (obsolete tag?)
Missing object of tag v2.6.12-rc3... different source (obsolete tag?)
Missing object of tag v2.6.12-rc4... different source (obsolete tag?)
Missing object of tag v2.6.12-rc5... different source (obsolete tag?)
Missing object of tag v2.6.12-rc6... different source (obsolete tag?)
Missing object of tag v2.6.13-rc1... different source (obsolete tag?)
Missing object of tag v2.6.13-rc2... different source (obsolete tag?)
--
Russell King
^ permalink raw reply
* Re: qgit-0.7
From: Ingo Molnar @ 2005-07-10 10:01 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050709081512.33503.qmail@web26306.mail.ukl.yahoo.com>
* Marco Costalba <mcostalba@yahoo.it> wrote:
> Here is qgit-0.7, a GUI git viewer.
>
> you can download from:
>
> http://prdownloads.sourceforge.net/qgit/qgit-0.7.tar.gz?download
>
>
> This time a small changelog, but a lot of work ;-)
>
> - rewrite of graph drawing
> - start-up loading: switch to use git-rev-list --topo-order
> - final fixes to annotation
> - cache of file lists to speed-up loading of file names
> - added color background on heads
the good news: it's really fast now and very usable for browsing
changes. Kudos!
the bad news: except for annotations. I started qgit in the current
kernel GIT repository, and clicked on the following commit:
5bbcfd9000887c0da7d57cc7b3ac869fc0dd5aa9
then i clicked on sched.c to see the annotated file. Firstly, it took
roughly 2 minutes (!) for the annotated sched.c to show up. All the qgit
windows were fully frozen during that time, no refreshes or anything.
My kernel tree was fully cached in RAM, so it was pure CPU overhead
(qgit was taking 99% of CPU time). It is clearly not usable in this
form.
then the annotations were plain wrong. Almost all lines are attributed
to Tony Luck, while much of the file comes from the initial repository.
So something's quite fishy here. Also, a number of lines were attributed
to 'merge', which isnt very informative.
Ingo
^ permalink raw reply
* Re: qgit-0.7
From: Marco Costalba @ 2005-07-10 12:25 UTC (permalink / raw)
To: mingo; +Cc: git
Ingo Molnar wrote:
>
>the bad news: except for annotations. I started qgit in the current
>kernel GIT repository, and clicked on the following commit:
>
> 5bbcfd9000887c0da7d57cc7b3ac869fc0dd5aa9
>
>then i clicked on sched.c to see the annotated file.
Interesting enough sched.c is one of the files I used as my internal test of
annotate function.
I test again annotate with commit 5bbcfd9000887c0da7d57cc7b3ac869fc0dd5aa9 but
my numbers are:
123 revisions in history list
4 seconds to show file content of rev 5bbcfd9000887c0da7d57cc7b3ac869fc0dd5aa9
16 seconds after annotate is shown
No 'Merge' string found
And no freeze at all on my box also because of some calls
to main event loop (qApp->processEvents()) scattered along the heaviest routines.
So I cannot reproduce the bug. Please can you be so kind to apply this:
--- a/src/annotate.cpp
+++ b/src/annotate.cpp
@@ -198,7 +198,7 @@ void Annotate::getReachability(ReachList
}
}
}
- //printReachList(rl);
+ printReachList(rl);
}
QString Annotate::getRoot(SRef sha, const ReachList& rl) {
and send me the output?
>
>then the annotations were plain wrong. Almost all lines are attributed
>to Tony Luck, while much of the file comes from the initial repository.
>So something's quite fishy here.
This is just a choice, peraphs wrong ;-). Because it is possible to call
annotate at any time, also while loading, snapshotting the history,
there is no a univoque meaning of "Inital import" so I choose first rev in list's author
instead. But anyway, this is the patch (above the first one)
--- a/src/annotate.cpp
+++ b/src/annotate.cpp
@@ -273,7 +273,7 @@ QStringList Annotate::getFirstAnnotation
QString fileSHA = rf.filesSHA[pos];
git->getFile(fileSHA, NULL, true); // calls mainExec and event loop
int lineNum = git->mainBuffer.contains('\n');
- QString author = getAuthor(shaHist[idx], shaHist);
+ QString author = "Initial import";
QStringList first;
first.insert(first.begin(), lineNum, author);
return first;
Also, a number of lines were attributed
>to 'merge', which isnt very informative.
>
This is not a choice but a bad behaviour. 'Merge' is used as author name
as a mark to help unify() routine to join 2 branches annotations and
should be substituted by second branch author if everything it is ok.
This is not your case ;-).
Marco
__________________________________
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Russell King @ 2005-07-10 12:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Tony Luck, Petr Baudis, git
In-Reply-To: <7v4qb3uo63.fsf@assigned-by-dhcp.cox.net>
On Sun, Jul 10, 2005 at 12:15:48AM -0700, Junio C Hamano wrote:
> As a workaround until Cogito gets updated, would it help to have
> the environment variable GIT_ALTERNATE_OBJECT_DIRECTORIES
> pointing at the untouched copy of Linus tree's .git/objects/
> directory? All your other trees would find the objects in your
> copied-Linus tree (including packed one) available to them
> already and hopefully pull breakage does not even have to touch
> those objects.
That seems to work, thanks. I think this is a good idea anyway -
it seems to mean that each working tree ends up with an empty set of
.git/objects/* directories. When new work is done in a tree, the
corresponding objects then appear, and only these objects need
transferring upstream.
It means that rsync --delete-after can (in theory) be used when
making changes available to the upstream maintainer.
--
Russell King
^ permalink raw reply
* Re: qgit-0.7
From: Ingo Molnar @ 2005-07-10 13:43 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050710122531.15175.qmail@web26303.mail.ukl.yahoo.com>
* Marco Costalba <mcostalba@yahoo.it> wrote:
> So I cannot reproduce the bug. [...]
weird - i cannot reproduce it either anymore, and annotate works now as
advertised - it's fast and accurate as far as i checked. But i synced to
the latest tree meanwhile. Perhaps i had an inconsistent tree?
(i'll keep an eye on this, i've uncommented that printout, so if it ever
happens again i'll have the data.)
now that everything is working fine, may i suggest improvements? :-)
Firstly, now i'm listed as the author for most portions of sched.c,
which is accurate for a fair portion of that, but is only done by qgit
because i happened to be the author of the first commit. So it would be
more accurate to denote version 1's author as empty (or with some other,
nonintrusive string that shows that this file came here due to the
initial commit)? We dont know the full history yet, because the current
DB's history starts at 2.6.12-rc2, with a full sched.c file. (I think an
empty author field would reflect version #1's authorship most
accurately, and would be the visually least intrusive.)
Ingo
^ permalink raw reply
* Re: cogito Mac OS X compatibility
From: Petr Baudis @ 2005-07-10 14:29 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <42CF0D9F.8040909@gmail.com>
Dear diary, on Sat, Jul 09, 2005 at 01:34:55AM CEST, I got a letter
where Bryan Larsen <bryan.larsen@gmail.com> told me that...
> On Mac OS X
>
> $ cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git
> defaulting to local storage area
> 19:11:10
> URL:http://www.kernel.org/pub/scm/cogito/cogito.git/refs/heads/master
> [41/41] -> "refs/heads/origin" [1]
> /Users/blarsen/bin/cg-pull: line 82: 0 + : syntax error: operand
> expected (error token is " ")
> cg-pull: objects pull failed
> cg-init: pull failed
That's strange. I assume you don't have the stat utility, but that
shouldn't matter - Cogito has own stat stub to use in those cases. Could
you please put some debugging stuff into stat() in cg-Xlib to see what's
going on? (Beware, cg-pull calls it with 2>/dev/null.) Thanks.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: What broke snapshots now?
From: David Woodhouse @ 2005-07-10 14:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <1120952292.23706.49.camel@baythorne.infradead.org>
On Sun, 2005-07-10 at 00:38 +0100, David Woodhouse wrote:
> Doh. I thought I'd already done that, but in fact that was for the
> scripts which feed the mailing list, while the snapshot script kept
> using my copy.
Ok, the snapshot script starts working again if I change a few
environment variables to match what the tools now expect.
Now the mailing list feed isn't happy though -- it stopped being able to
pull from your tree at around 0600 UTC (which I think is then the last
DRM fix was added). I got this when trying to update...
Tree change: 0109fd37046de64e8459f8c4f4706df9ac7cc82c:f179bc77d09b9087bfc559d0368bba350342ac76
error: cannot read sha1_file for ce68a60e5c503aaef0a98f8d754effb6c7d9ee99
fatal: unable to read destination tree (ce68a60e5c503aaef0a98f8d754effb6c7d9ee99)
Applying changes...
Fast-forwarding 0109fd37046de64e8459f8c4f4706df9ac7cc82c -> f179bc77d09b9087bfc559d0368bba350342ac76
on top of 0109fd37046de64e8459f8c4f4706df9ac7cc82c...
error: cannot read sha1_file for ce68a60e5c503aaef0a98f8d754effb6c7d9ee99
fatal: failed to unpack tree object f179bc77d09b9087bfc559d0368bba350342ac76
Since it's just a fast-forward, I just copied the 'origin' tag into the
'master' to move it forward. But it's still not happy:
hera /home/dwmw2/git/mail-2.6 $ cg-diff -r 0109fd37046de64e8459f8c4f4706df9ac7cc82c:f179bc77d09b9087bfc559d0368bba350342ac76
error: cannot read sha1_file for ce68a60e5c503aaef0a98f8d754effb6c7d9ee99
fatal: unable to read destination tree (ce68a60e5c503aaef0a98f8d754effb6c7d9ee99)
--
dwmw2
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Petr Baudis @ 2005-07-10 14:59 UTC (permalink / raw)
To: Russell King; +Cc: git
In-Reply-To: <20050710090914.B11765@flint.arm.linux.org.uk>
Dear diary, on Sun, Jul 10, 2005 at 10:09:14AM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> On Sat, Jul 09, 2005 at 10:58:18PM +0100, Russell King wrote:
> > $ mv .git/objects/pack/* .git/
> > $ for i in .git/*.pack; do git-unpack-objects < $i; done
> > Unpacking 55435 objects
> > fatal: inflate returned -3
>
> This morning's cg-update gave these new errors:
>
> receiving file list ... done
>
> wrote 86 bytes read 192 bytes 556.00 bytes/sec
> total size is 410 speedup is 1.47
> Missing object of tag v2.6.11... different source (obsolete tag?)
> Missing object of tag v2.6.11-tree... different source (obsolete tag?)
> Missing object of tag v2.6.12... different source (obsolete tag?)
> Missing object of tag v2.6.12-rc2... different source (obsolete tag?)
> Missing object of tag v2.6.12-rc3... different source (obsolete tag?)
> Missing object of tag v2.6.12-rc4... different source (obsolete tag?)
> Missing object of tag v2.6.12-rc5... different source (obsolete tag?)
> Missing object of tag v2.6.12-rc6... different source (obsolete tag?)
> Missing object of tag v2.6.13-rc1... different source (obsolete tag?)
> Missing object of tag v2.6.13-rc2... different source (obsolete tag?)
Ok, cg-pull didn't quite handle this. I've fixed it so that it should
reasonably handle it now. Hopefully.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Petr Baudis @ 2005-07-10 15:06 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.07.09.21.04.29.263374@smurf.noris.de>
Dear diary, on Sat, Jul 09, 2005 at 11:04:37PM CEST, I got a letter
where Matthias Urlichs <smurf@smurf.noris.de> told me that...
> > o Is there a way to force git to apply and safe the rejects?
>
> Well, you can use "patch -p1 ..." directly, and manually add the files it
> created to the object cache. Personally I wouldn't, if at all possible.
Or you can do cg-patch, which should handle that for you properly as
well. I think the "no fuzz" approach is hyper-paranoid. I deal with
small or larger fuzz all the time when I'm reordering patches or
applying them to a few hours younger version than they were based on. I
think the restriction it imposes is overly draconian here and doesn't
trust the developer to know what he is doing as much as it should. (And
that's why cg-patch doesn't use git-apply. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: [PATCH 1/3] add -N option to cg-add (resent)
From: Petr Baudis @ 2005-07-10 15:17 UTC (permalink / raw)
To: Bryan Larsen; +Cc: bryan.larsen, git
In-Reply-To: <20050709104011.26763.37732.sendpatchset@bryan-larsens-ibook-g4.local>
Dear diary, on Sat, Jul 09, 2005 at 12:40:22PM CEST, I got a letter
where Bryan Larsen <bryanlarsen@yahoo.com> told me that...
> (resending cogito patches)
>
> Add the -N option to cg-add.
>
> Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
Applied all three patches. Note that I'm a bit happier when they are a
little more maintainer-friendly - it helps to describe why are you
resending them, and be a little more verbose in the accompanying
message. :-)
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Linus kernel tree corrupt?
From: Petr Baudis @ 2005-07-10 15:23 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Russell King, Tony Luck, Jon Smirl, git
In-Reply-To: <42D01174.4050501@zytor.com>
Dear diary, on Sat, Jul 09, 2005 at 08:03:32PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Petr Baudis wrote:
> >
> >Yes, please do. I deprecated rsync a day before Linus "broke" http-pull.
> >It's un-deprecated again for now in the latest Cogito.
> >
>
> Presumably for packed repos you want to drop the --ignore-existing
> --whole-file options I assume?
It _is_ unsafe for individual objects, and your packfile will be corrupt
if you break it in the middle and not have --whole-file turned on, I
assume. It would be ideal if we could make rsync allow resuming download
of the file if interrupted, but not under the final name but in that
hidden file it uses.
> sent 339 bytes received 1802 bytes 4282.00 bytes/sec
> total size is 410 speedup is 0.19
> Missing object of tag v2.6.11... different source (obsolete tag?)
> Missing object of tag v2.6.11-tree... different source (obsolete tag?)
> Missing object of tag v2.6.12... different source (obsolete tag?)
> Missing object of tag v2.6.12-rc2... different source (obsolete tag?)
> Missing object of tag v2.6.12-rc3... different source (obsolete tag?)
> Missing object of tag v2.6.12-rc4... different source (obsolete tag?)
> Missing object of tag v2.6.12-rc5... different source (obsolete tag?)
> Missing object of tag v2.6.12-rc6... different source (obsolete tag?)
> Missing object of tag v2.6.13-rc1... different source (obsolete tag?)
> Missing object of tag v2.6.13-rc2... different source (obsolete tag?)
> New branch: 0109fd37046de64e8459f8c4f4706df9ac7cc82c
> Cloned (origin
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> available as branch "origin")
> Cloned to ./ (origin
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> available as branch "origin")
>
> Is the "missing objects" thing spurious?
Yes, already fixed. Will release 0.12.1 soon.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox