* Re: cg-init bug
From: Radoslaw Szkodzinski @ 2005-06-05 16:10 UTC (permalink / raw)
To: Zack Brown; +Cc: pasky, git
In-Reply-To: <20050605153053.GA6890@tumblerings.org>
Zack Brown wrote:
>Hi,
>
>I've been tracking Cogito. This problem occurred with Cogito version
>1e2673d606dd39dc44b4eed2204ba349a448bc4d
>
>I have a directory tree with several layers of subdirectories and about 1700
>files. I tried to convert it to a git repository with 'cg-init'.
>
>
I think an ls -l of the repo would be useful... if it's not that big.
If it is, you may have hit the limitation of the length of command line.
If it's so, repeat the commands.
However, if I'd want to add everything to the repo, I'd do:
cg-status | sed "s/? //" | xargs cg-add
AstralStorm
^ permalink raw reply
* Re: [PATCH] git-daemon server
From: Linus Torvalds @ 2005-06-05 16:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vzmu5b8o6.fsf@assigned-by-dhcp.cox.net>
On Sat, 4 Jun 2005, Junio C Hamano wrote:
>
> Linus, can your workflow grok things like this, or do you prefer
> patch submission to use traditional diff format without renames?
I haven't made "git-apply" do the final part yet: it doesn't actually
apply anything. So I'm still using standard patch in my workflow.
But that's largely been because I haven't been hugely motivated to fixing
it yet. I will now correct that.
Let's see if I can do the last mile now.
Linus
^ permalink raw reply
* Re: cg-init bug
From: Zack Brown @ 2005-06-05 16:27 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: pasky, git
In-Reply-To: <42A323F4.2010109@gorzow.mm.pl>
On Sun, Jun 05, 2005 at 06:10:28PM +0200, Radoslaw Szkodzinski wrote:
> Zack Brown wrote:
>
> >Hi,
> >
> >I've been tracking Cogito. This problem occurred with Cogito version
> >1e2673d606dd39dc44b4eed2204ba349a448bc4d
> >
> >I have a directory tree with several layers of subdirectories and about 1700
> >files. I tried to convert it to a git repository with 'cg-init'.
> >
> >
> I think an ls -l of the repo would be useful... if it's not that big.
It's over 2000 lines, I'm not sure if that's considered big. But it's just
regular files and directories with regular-length names. Here's a sample:
-----------------------------------------------------------------------------
...
./kde/trans/german:
total 76
-rw-rw-r-- 1 zbrown zbrown 230 Jan 19 2003 Makefile
-rw-rw-r-- 1 zbrown zbrown 20 Jan 19 2003 Makefile.encoding
-rw-rw-r-- 1 zbrown zbrown 15712 Jan 19 2003 kde20020522_37.xml
-rw-rw-r-- 1 zbrown zbrown 15669 Jan 19 2003 kde20020522_37.xml.old
-rw-rw-r-- 1 zbrown zbrown 12941 Jan 19 2003 kde20020605_38.xml
-rw-rw-r-- 1 zbrown zbrown 464 Nov 16 2003 latest.txt
-rw-rw-r-- 1 zbrown zbrown 32 Jan 19 2003 latest.xml
drwxrwxr-x 2 zbrown zbrown 4096 Nov 16 2003 quotes/
drwxrwxr-x 2 zbrown zbrown 4096 Nov 16 2003 raw/
drwxrwxr-x 2 zbrown zbrown 4096 Nov 16 2003 topics/
./kde/trans/german/quotes:
total 0
./kde/trans/german/raw:
total 0
./kde/trans/german/topics:
total 0
./kde/trans/spanish:
total 140
-rw-rw-r-- 1 zbrown zbrown 230 Jan 19 2003 Makefile
-rw-rw-r-- 1 zbrown zbrown 20 Jan 19 2003 Makefile.encoding
-rw-rw-r-- 1 zbrown zbrown 198 Jan 19 2003 index.xml.bak
-rw-rw-r-- 1 zbrown zbrown 24211 Jan 19 2003 kde20020118_31.xml
-rw-rw-r-- 1 zbrown zbrown 12061 Jan 19 2003 kde20020215_32.xml
-rw-rw-r-- 1 zbrown zbrown 12748 Jan 19 2003 kde20020222_33.xml
-rw-rw-r-- 1 zbrown zbrown 12468 Jan 19 2003 kde20020605_38.xml
-rw-rw-r-- 1 zbrown zbrown 18517 Jan 19 2003 kde20020619_39.xml
-rw-rw-r-- 1 zbrown zbrown 17001 Jan 19 2003 kde20020710_40.xml
-rw-rw-r-- 1 zbrown zbrown 464 Nov 16 2003 latest.txt
-rw-rw-r-- 1 zbrown zbrown 32 Jan 19 2003 latest.xml
drwxrwxr-x 2 zbrown zbrown 4096 Nov 16 2003 quotes/
drwxrwxr-x 2 zbrown zbrown 4096 Nov 16 2003 raw/
drwxrwxr-x 2 zbrown zbrown 4096 Nov 16 2003 topics/
./kde/trans/spanish/quotes:
total 0
...
-----------------------------------------------------------------------------
> If it is, you may have hit the limitation of the length of command line.
> If it's so, repeat the commands.
I did that when I first saw the problem, and although it did seem to add a few
dozen files at a time, eventually it refused to add any more files, even though
cg-status reported many files still as '?'.
>
> However, if I'd want to add everything to the repo, I'd do:
> cg-status | sed "s/? //" | xargs cg-add
But shouldn't cg-init take care of that for me automatically when I create the
repo?
Be well,
Zack
>
> AstralStorm
--
Zack Brown
^ permalink raw reply
* Re: [PATCH] pull: gracefully recover from delta retrieval failure.
From: Jason McMullan @ 2005-06-05 16:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v4qcde3j9.fsf@assigned-by-dhcp.cox.net>
On Sat, 2005-06-04 at 23:11 -0700, Junio C Hamano wrote:
> This addresses a concern raised by Jason McMullan in the mailing
> list discussion. After retrieving and storing a potentially
> deltified object, pull logic tries to check and fulfil its delta
> dependency. When the pull procedure is killed at this point,
> however, there was no easy way to recover by re-running pull,
> since next run would have found that we already have that
> deltified object and happily reported success, without really
> checking its delta dependency is satisfied.
I still think it would be much better if you didn't place unverified
objects in the database in the first place. You've taken care of delta
object recovery, yes, but what about unsatisfied tree objects? Or commit
objects? Does your algorithm require full depth scanning of the
entire repository that is descended from the commit head?
I much prefer to always leave the database in a consistent state, that
way you only have to do O(number-of-retrieved-objects) verifications,
not O(number-of-commit-tree-ancestors) verifications.
Or am I misunderstanding your technique here?
Sorry about being a pest, but this worries me. Please assuage my fears.
(Or, if you'd like, I can rework pull.c to use the
verification-before-store technique I used in my git-daemon patch, so
all the *-pull mechanisms will be 'safe')
^ permalink raw reply
* Re: [PATCH] git-daemon server
From: Jason McMullan @ 2005-06-05 16:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: GIT Mailling list
In-Reply-To: <Pine.LNX.4.58.0506031410560.1876@ppc970.osdl.org>
On Fri, 2005-06-03 at 14:38 -0700, Linus Torvalds wrote:
> Anyway, with _something_ like the above you could do something like
>
> git-sync --exec "ssh master.kernel.org git-sync" ....
>
> and it would do the obvious thing.
Sounds good. I'll implement that right after I put in tags support, and
merge by verify-before-write pull mechanism into pull.c, so everyone
can use it.
And, it looks like 'git-sync' is the decided name? Excellent!
^ permalink raw reply
* Re: [PATCH] git-daemon server
From: Jason McMullan @ 2005-06-05 16:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.58.0506031450190.1876@ppc970.osdl.org>
On Fri, 2005-06-03 at 14:59 -0700, Linus Torvalds wrote:
> Me, I want to have a fairly simple script that does the equivalent of what
> I do now for pushing:
>
> rsync -av --delete --exclude-from=.exclude .git/ master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> except I'd want it to do the locking and the "only accept trivial pushes"
> stuff (ie no merging, just a pure update).
$ GITCONNECTION="--tcp ...."
$ git-sync $GITCONNECTION head master master `cat .git/HEAD`
(Yeah, the 'master master' is a cheezy way to do an update, but
if you're the only one who can update the head, it's a non-issue)
^ permalink raw reply
* Re: [PATCH] pull: gracefully recover from delta retrieval failure.
From: Daniel Barkalow @ 2005-06-05 17:24 UTC (permalink / raw)
To: Jason McMullan; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <1117989532.10424.7.camel@port.evillabs.net>
On Sun, 5 Jun 2005, Jason McMullan wrote:
> (Or, if you'd like, I can rework pull.c to use the
> verification-before-store technique I used in my git-daemon patch, so
> all the *-pull mechanisms will be 'safe')
The reasons I don't really want a verification-before-store are:
- I'd like things to be resumable on error; if you've already got a bunch
of stuff and then the connection breaks, you should already have the
things you got; so, at least, the temporary locations should be
something predictable from the hash.
- I'd like the user to be able to intentionally get partial repositories
of various sorts, and still have consistant information. If I don't
have anything written that's not in mainline, and I'm not going to be
applying other people's patches, and I don't have an up-to-date
repository, I'd like to be able to pull just mainline's head commit and
tree, and work from there. I don't need the history unless I want to
look up changes or want to merge something that's not derived entirely
from the head I've got.
So what I'd really like is something where you store whatever objects you
have, and also have extra information about what objects you know about
but don't have and what objects you've gotten completely. Of course, this
needs to be kept manageable.
(Along the lines of the second one, there's a variety of partial
information which is sufficient for various purposes. If I trust that
Linus's latest tree is based on my most recent pull from him, I can
fast-forward with just the tree. I can also merge his tree into mine with
just the commits and his latest tree, since I must already have any common
ancestors. In all these cases, I may want to streamline my process by
doing "pull tree; pull all &; checkout" or
"pull tree,commits; pull all &; merge", so that I can start on further
development while the rest of the information fills in.)
So I'd greatly prefer to keep the metadata of what objects we have
explicitly, rather than implicitly in the presence or absence of files in
the object directory. Also, for objects which we expect to be missing, it
would be good to keep info on where we expect to be able to get
them. Then, if I'm wrong about what I actually needed, it doesn't need me
to tell it again where to get things.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: cg-init bug
From: Petr Baudis @ 2005-06-05 17:28 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20050605153053.GA6890@tumblerings.org>
Dear diary, on Sun, Jun 05, 2005 at 05:30:53PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> Hi,
Hello,
> I've been tracking Cogito. This problem occurred with Cogito version
> 1e2673d606dd39dc44b4eed2204ba349a448bc4d
>
> I have a directory tree with several layers of subdirectories and about 1700
> files. I tried to convert it to a git repository with 'cg-init'.
>
> The first thing I noticed was that not all the files and subdirectories had been
> added. Doing a cg-status listed many files with '?' in front of them.
>
> I tried adding these files with "cg-add */*", "cg-add */*/*" etc, followed by
> "cg-commit", and this seemed at first glance to work. I was able to reduce
> the number of files reported by "cg-status". But eventually "cg-add" would
> say there were no files left to add, while "cg-status" would still list many
> files unadded. It seemed that "cg-add" would only selectively add files.
>
> At that point I blew away the .git directory and gave up on repo-izing that
> project for now.
>
> I can reproduce this problem easily. Please let me know if you need any more
> information.
what are the files it would refuse to add?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] pull: gracefully recover from delta retrieval failure.
From: Junio C Hamano @ 2005-06-05 17:46 UTC (permalink / raw)
To: Jason McMullan; +Cc: Linus Torvalds, git
In-Reply-To: <1117989532.10424.7.camel@port.evillabs.net>
>>>>> "JM" == Jason McMullan <jason.mcmullan@timesys.com> writes:
JM> Sorry about being a pest, but this worries me. Please assuage my fears.
Earlier I said I suspected that the original code mishandled
recovery from a botched tree/commit dependent transfer, but that
was not the case. The last test in the new test script I added
in the patch you are responding to covers that case.
JM> (Or, if you'd like, I can rework pull.c to use the
JM> verification-before-store technique I used in my git-daemon patch, so
JM> all the *-pull mechanisms will be 'safe')
I would appreciate the offer. I, however, would have to warn
you that the "problem" lies in the way the current pull
structure devides responsibility between the pull.c and transfer
backends. The pull.c implements the dependency logic, and
transfer backends are to populate the database while being
oblivious of that logic. From the purist point of view (I am
sympathetic to your "place only the verified objects in the
database" principle), I am not entirely happy with that
division, but at the same time I understand why it is done that
way and even like it from practical standpoint. Otherwise you
need to keep a bunch of objects somewhere outside the database
along with the list of "things to rename to the final database
name when we are done". You would somehow need to do clean-up
when we fail in the middle _anyway_.
In other words, the current structure is optimized for non-
failure case, as it should be. The original implementation
(credit goes to Dan Barkalow) knew how to recover from failed
transfer (including the case that you first pull with -c or -t
without using -a to miss some required objects to satisfy -a) by
simply running pull again, and with the --recover flag, it now
knows how to recover from failed deltified object transfer as
well.
^ permalink raw reply
* Re: SSH pull problems
From: Daniel Barkalow @ 2005-06-05 17:47 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: git
In-Reply-To: <42A1A716.9030304@gorzow.mm.pl>
On Sat, 4 Jun 2005, Radoslaw Szkodzinski wrote:
> I had some problems today with git+ssh protocol.
> First, when using cg-clone, it couldn't execute cg-rpush, although it's
> there in /usr/local.
> Maybe that has something to do with that being added to the path in
> /etc/profile.
I haven't used recent Cogito, so I'm not sure, but it might actually want
git-rpush rather than cg-rpush? Or it might be a permissions issue?
> Second, I don't know how to specify the port number,
> the typical notation of git+ssh://xyz:port/repo didn't work.
I haven't made it understand port numbers yet; it should be pretty easy,
though, if you want to do it. You'd probably have a better chance of
getting it right than I would, if you've got an SSH server on a
non-default port to test against. Just parse out the part of "host" after
the : and make it a "-p" option in the execlp in rsh.c.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: SSH pull problems
From: Petr Baudis @ 2005-06-05 17:50 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: git
In-Reply-To: <42A1A716.9030304@gorzow.mm.pl>
Dear diary, on Sat, Jun 04, 2005 at 03:05:26PM CEST, I got a letter
where Radoslaw Szkodzinski <astralstorm@gorzow.mm.pl> told me that...
> I had some problems today with git+ssh protocol.
> First, when using cg-clone, it couldn't execute cg-rpush, although it's
> there in /usr/local.
> Maybe that has something to do with that being added to the path in
> /etc/profile.
>
> Second, I don't know how to specify the port number,
> the typical notation of git+ssh://xyz:port/repo didn't work.
>
> Anybody knows what to do with these?
> SSH would be very useful for me if it worked right.
If you are staying at the Cogito's tip, there was an incompatible
protocol change introduced recently, so make sure you have the same
Cogito version on both sides.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: cg-init bug
From: Zack Brown @ 2005-06-05 17:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050605172854.GF17462@pasky.ji.cz>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 35858 bytes --]
On Sun, Jun 05, 2005 at 07:28:54PM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Jun 05, 2005 at 05:30:53PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > Hi,
>
> Hello,
>
> > I've been tracking Cogito. This problem occurred with Cogito version
> > 1e2673d606dd39dc44b4eed2204ba349a448bc4d
> >
> > I have a directory tree with several layers of subdirectories and about 1700
> > files. I tried to convert it to a git repository with 'cg-init'.
> >
> > The first thing I noticed was that not all the files and subdirectories had been
> > added. Doing a cg-status listed many files with '?' in front of them.
> >
> > I tried adding these files with "cg-add */*", "cg-add */*/*" etc, followed by
> > "cg-commit", and this seemed at first glance to work. I was able to reduce
> > the number of files reported by "cg-status". But eventually "cg-add" would
> > say there were no files left to add, while "cg-status" would still list many
> > files unadded. It seemed that "cg-add" would only selectively add files.
> >
> > At that point I blew away the .git directory and gave up on repo-izing that
> > project for now.
> >
> > I can reproduce this problem easily. Please let me know if you need any more
> > information.
>
> what are the files it would refuse to add?
Depending on how I check, I get very different lists. I'll include both in this email.
If I do the 'cg-init' on the full source.cogito directory, then do a 'cg-clone'
into a new source.cogtst directory, here is the result of a comparison:
$ diff -ur source.cogito/ source.cogtst/|grep -v "\.git"|cut -d '/' -f 2-|sed -e "s/: /\//"
/GNUe
/Makefile
/Makefile.cousinraw
/Makefile.cousinsite
/Makefile.globalvars
/arch
/asleep.xml
/author.xml
/authors
/bin
/crash.xml
/debian
/debian-hurd
/devel.xml
/donations.xml
/editor.xml
/favicon.ico
/gimp
/git
/gpl.txt
/help.xml
/index.xml
/irc.xml
/kde
kernel-traffic/quotes
kernel-traffic/raw
kernel-traffic/stats
kernel-traffic/topics
kernel-traffic/trans/czech/Makefile
kernel-traffic/trans/czech/Makefile.encoding
kernel-traffic/trans/czech/index.xml
kernel-traffic/trans/czech/kt20000110_50.xml.bak
kernel-traffic/trans/czech/kt20000117_51.xml.bak
kernel-traffic/trans/czech/kt20000124_52.xml.bak
kernel-traffic/trans/czech/kt20000207_53.xml.bak
kernel-traffic/trans/czech/kt20000214_54.xml.bak
kernel-traffic/trans/czech/kt20000221_55.xml.bak
kernel-traffic/trans/czech/kt20000228_56.xml.bak
kernel-traffic/trans/czech/kt20000306_57.xml.bak
kernel-traffic/trans/czech/kt20000313_58.xml.bak
kernel-traffic/trans/czech/kt20000320_59.xml.bak
kernel-traffic/trans/czech/kt20000327_60.xml.bak
kernel-traffic/trans/czech/kt20000403_61.xml.bak
kernel-traffic/trans/czech/kt20000410_62.xml.bak
kernel-traffic/trans/czech/kt20000417_63.xml.bak
kernel-traffic/trans/czech/kt20000424_64.xml.bak
kernel-traffic/trans/czech/kt20000501_65.xml.bak
kernel-traffic/trans/czech/kt20000507_66.xml.bak
kernel-traffic/trans/czech/kt20000515_67.xml.bak
kernel-traffic/trans/czech/kt20000522_68.xml.bak
kernel-traffic/trans/czech/kt20000529_69.xml.bak
kernel-traffic/trans/czech/kt20000605_70.xml.bak
kernel-traffic/trans/czech/kt20000612_71.xml.bak
kernel-traffic/trans/czech/kt20000619_72.xml.bak
kernel-traffic/trans/czech/kt20000626_73.xml.bak
kernel-traffic/trans/czech/kt20000703_74.xml.bak
kernel-traffic/trans/czech/kt20000710_75.xml.bak
kernel-traffic/trans/czech/kt20000717_76.xml.bak
kernel-traffic/trans/czech/kt20000724_77.xml.bak
kernel-traffic/trans/czech/kt20000731_78.xml.bak
kernel-traffic/trans/czech/kt20000807_79.xml.bak
kernel-traffic/trans/czech/kt20000814_80.xml.bak
kernel-traffic/trans/czech/kt20000821_81.xml.bak
kernel-traffic/trans/czech/kt20000828_82.xml.bak
kernel-traffic/trans/czech/kt20000904_83.xml.bak
kernel-traffic/trans/czech/kt20000911_84.xml.bak
kernel-traffic/trans/czech/kt20000918_85.xml.bak
kernel-traffic/trans/czech/kt20000925_86.xml.bak
kernel-traffic/trans/czech/kt20001002_87.xml.bak
kernel-traffic/trans/czech/kt20001010_88.xml.bak
kernel-traffic/trans/czech/kt20001016_89.xml.bak
kernel-traffic/trans/czech/kt20001023_90.xml.bak
kernel-traffic/trans/czech/kt20001030_91.xml.bak
kernel-traffic/trans/czech/kt20001106_92.xml.bak
kernel-traffic/trans/czech/kt20001113_93.xml.bak
kernel-traffic/trans/czech/kt20001120_94.xml.bak
kernel-traffic/trans/czech/kt20001127_95.xml.bak
kernel-traffic/trans/czech/kt20001204_96.xml.bak
kernel-traffic/trans/czech/kt20001211_97.xml.bak
kernel-traffic/trans/czech/kt20001218_98.xml.bak
kernel-traffic/trans/czech/kt20001225_99.xml.bak
kernel-traffic/trans/czech/kt20010101_100.xml.bak
kernel-traffic/trans/czech/kt20010108_101.xml.bak
kernel-traffic/trans/czech/kt20010112_102.xml.bak
kernel-traffic/trans/czech/kt20010119_103.xml.bak
kernel-traffic/trans/czech/kt20010126_104.xml.bak
kernel-traffic/trans/czech/kt20010202_105.xml.bak
kernel-traffic/trans/czech/kt20010209_106.xml.bak
kernel-traffic/trans/czech/kt20010216_107.xml.bak
kernel-traffic/trans/czech/kt20010223_108.xml.bak
kernel-traffic/trans/czech/kt20010302_109.xml.bak
kernel-traffic/trans/czech/kt20010309_110.xml.bak
kernel-traffic/trans/czech/kt20010316_111.xml.bak
kernel-traffic/trans/czech/kt20010323_112.xml.bak
kernel-traffic/trans/czech/kt20010330_113.xml.bak
kernel-traffic/trans/czech/kt20010416_114.xml.bak
kernel-traffic/trans/czech/kt20010917_133.xml.bak
kernel-traffic/trans/czech/kt20020128_152.xml.bak
kernel-traffic/trans/czech/kt20020211_153.xml.bak
kernel-traffic/trans/czech/kt20020218_154.xml.bak
kernel-traffic/trans/czech/kt20020225_155.xml.bak
kernel-traffic/trans/czech/kt20020304_156.xml.bak
kernel-traffic/trans/czech/kt20020311_157.xml.bak
kernel-traffic/trans/czech/kt20020318_158.xml.bak
kernel-traffic/trans/czech/kt20020325_159.xml.bak
kernel-traffic/trans/czech/kt20020401_160.xml.bak
kernel-traffic/trans/czech/kt20020407_161.xml.bak
kernel-traffic/trans/czech/kt20020415_162.xml.bak
kernel-traffic/trans/czech/kt20020422_163.xml.bak
kernel-traffic/trans/czech/kt20020429_164.xml.bak
kernel-traffic/trans/czech/kt20020506_165.xml.bak
kernel-traffic/trans/czech/kt20020513_166.xml.bak
kernel-traffic/trans/czech/kt20020520_167.xml.bak
kernel-traffic/trans/czech/kt20020527_168.xml.bak
kernel-traffic/trans/czech/kt20020603_169.xml.bak
kernel-traffic/trans/czech/kt20020609_170.xml.bak
kernel-traffic/trans/czech/kt20020617_171.xml.bak
kernel-traffic/trans/czech/kt20020624_172.xml.bak
kernel-traffic/trans/czech/kt20020708_174.xml.bak
kernel-traffic/trans/czech/kt20020715_175.xml.bak
kernel-traffic/trans/czech/kt20020722_176.xml.bak
kernel-traffic/trans/czech/kt20020805_178.xml.bak
kernel-traffic/trans/czech/kt20020812_179.xml.bak
kernel-traffic/trans/czech/kt20020819_180.xml.bak
kernel-traffic/trans/czech/kt20020826_181.xml.bak
kernel-traffic/trans/czech/kt20020902_182.xml.bak
kernel-traffic/trans/czech/kt20020909_183.xml.bak
kernel-traffic/trans/czech/kt20020916_184.xml.bak
kernel-traffic/trans/czech/kt20020923_185.xml.bak
kernel-traffic/trans/czech/kt20020930_186.xml.bak
kernel-traffic/trans/czech/kt20021007_187.xml.bak
kernel-traffic/trans/czech/kt20021014_188.xml.bak
kernel-traffic/trans/czech/kt20021021_189.xml.bak
kernel-traffic/trans/czech/kt20021028_190.xml.bak
kernel-traffic/trans/czech/kt20021111_191.xml.bak
kernel-traffic/trans/czech/kt20021118_192.xml.bak
kernel-traffic/trans/czech/kt20021125_193.xml.bak
kernel-traffic/trans/czech/kt20021202_194.xml.bak
kernel-traffic/trans/czech/kt20021209_195.xml.bak
kernel-traffic/trans/czech/kt20021216_196.xml.bak
kernel-traffic/trans/czech/kt20021223_197.xml.bak
kernel-traffic/trans/czech/kt20021230_198.xml.bak
kernel-traffic/trans/czech/kt20030106_199.xml.bak
kernel-traffic/trans/czech/kt20030113_200.xml.bak
kernel-traffic/trans/czech/kt20030117_201.xml.bak
kernel-traffic/trans/czech/kt20030124_202.xml.bak
kernel-traffic/trans/czech/kt20030131_203.xml.bak
kernel-traffic/trans/czech/kt20030209_204.xml.bak
kernel-traffic/trans/czech/kt20030216_205.xml.bak
kernel-traffic/trans/czech/kt20030223_206.xml.bak
kernel-traffic/trans/czech/kt20030302_207.xml.bak
kernel-traffic/trans/czech/kt20030309_208.xml.bak
kernel-traffic/trans/czech/kt20030316_209.xml.bak
kernel-traffic/trans/czech/kt20030323_210.xml.bak
kernel-traffic/trans/czech/kt20030330_211.xml.bak
kernel-traffic/trans/czech/kt20030406_212.xml.bak
kernel-traffic/trans/czech/kt20030413_213.xml.bak
kernel-traffic/trans/czech/kt20030428_214.xml.bak
kernel-traffic/trans/czech/kt20030509_215.xml.bak
kernel-traffic/trans/czech/kt20030520_216.xml.bak
kernel-traffic/trans/czech/kt20030523_217.xml.bak
kernel-traffic/trans/czech/kt20030607_218.xml.bak
kernel-traffic/trans/czech/kt20030616_219.xml.bak
kernel-traffic/trans/czech/kt20030708_221.xml
kernel-traffic/trans/czech/kt20030710_222.xml
kernel-traffic/trans/czech/kt20030720_223.xml
kernel-traffic/trans/czech/kt20030730_224.xml
kernel-traffic/trans/czech/kt20030731_225.xml
kernel-traffic/trans/czech/kt20030805_226.xml.bak
kernel-traffic/trans/czech/kt20030811_227.xml
kernel-traffic/trans/czech/kt20030817_228.xml
kernel-traffic/trans/czech/kt20030908_229.xml
kernel-traffic/trans/czech/kt20030909_230.xml
kernel-traffic/trans/czech/kt20030910_231.xml
kernel-traffic/trans/czech/kt20030920_232.xml
kernel-traffic/trans/czech/kt20031004_233.xml
kernel-traffic/trans/czech/kt20031006_234.xml
kernel-traffic/trans/czech/kt20031024_235.xml
kernel-traffic/trans/czech/kt20031026_236.xml
kernel-traffic/trans/czech/kt20031026_237.xml
kernel-traffic/trans/czech/kt20031027_238.xml
kernel-traffic/trans/czech/kt20031101_239.xml
kernel-traffic/trans/czech/kt20031109_240.xml
kernel-traffic/trans/czech/kt20031116_241.xml
kernel-traffic/trans/czech/kt20031124_242.xml
kernel-traffic/trans/czech/kt20031201_243.xml
kernel-traffic/trans/czech/kt20031208_244.xml
kernel-traffic/trans/czech/kt20031214_245.xml
kernel-traffic/trans/czech/kt20031226_246.xml
kernel-traffic/trans/czech/kt20031231_247.xml
kernel-traffic/trans/czech/kt20040120_248.xml
kernel-traffic/trans/czech/kt20040127_249.xml
kernel-traffic/trans/czech/quotes
kernel-traffic/trans/czech/raw
kernel-traffic/trans/czech/topics
kernel-traffic/trans/french/quotes
kernel-traffic/trans/french/raw
kernel-traffic/trans/french/topics
kernel-traffic/trans/german/quotes
kernel-traffic/trans/german/raw
kernel-traffic/trans/german/topics
kernel-traffic/trans/polish/quotes
kernel-traffic/trans/polish/raw
kernel-traffic/trans/polish/topics
kernel-traffic/trans/spanish/quotes
kernel-traffic/trans/spanish/raw
kernel-traffic/trans/spanish/topics
reactos/quotes
reactos/raw
reactos/topics
reactos/trans
samba/quotes
samba/raw
samba/topics
slug-pearls/quotes
slug-pearls/raw
slug-pearls/topics
wine/quotes
wine/raw
wine/topics
wine/trans/polish/quotes
wine/trans/polish/raw
or about 222 files.
If instead of this I do a 'cg-status', I get the following output:
? GNUe/Makefile
? GNUe/back-issues.raw
? GNUe/gnue20011103_1.xml
? GNUe/gnue20011110_2.xml
? GNUe/gnue20011117_3.xml
? GNUe/gnue20011124_4.xml
? GNUe/gnue20011201_5.xml
? GNUe/gnue20011208_6.xml
? GNUe/gnue20011215_7.xml
? GNUe/gnue20011222_8.xml
? GNUe/gnue20011229_9.xml
? GNUe/gnue20020105_10.xml
? GNUe/gnue20020112_11.xml
? GNUe/gnue20020119_12.xml
? GNUe/gnue20020126_13.xml
? GNUe/gnue20020202_14.xml
? GNUe/gnue20020209_15.xml
? GNUe/gnue20020216_16.xml
? GNUe/gnue20020223_17.xml
? GNUe/gnue20020302_18.xml
? GNUe/gnue20020309_19.xml
? GNUe/gnue20020316_20.xml
? GNUe/gnue20020323_21.xml
? GNUe/gnue20020330_22.xml
? GNUe/gnue20020406_23.xml
? GNUe/gnue20020413_24.xml
? GNUe/gnue20020420_25.xml
? GNUe/gnue20020427_26.xml
? GNUe/gnue20020504_27.xml
? GNUe/gnue20020511_28.xml
? GNUe/gnue20020518_29.xml
? GNUe/gnue20020525_30.xml
? GNUe/gnue20020601_31.xml
? GNUe/gnue20020608_32.xml
? GNUe/gnue20020615_33.xml
? GNUe/gnue20020622_34.xml
? GNUe/gnue20020629_35.xml
? GNUe/gnue20020706_36.xml
? GNUe/gnue20020713_37.xml
? GNUe/gnue20020720_38.xml
? GNUe/gnue20020727_39.xml
? GNUe/gnue20020803_40.xml
? GNUe/gnue20020810_41.xml
? GNUe/gnue20020817_42.xml
? GNUe/gnue20020824_43.xml
? GNUe/gnue20020830_44.xml
? GNUe/gnue20020907_45.xml
? GNUe/gnue20020914_46.xml
? GNUe/gnue20020921_47.xml
? GNUe/gnue20020928_48.xml
? GNUe/gnue20021005_49.xml
? GNUe/gnue20021012_50.xml
? GNUe/gnue20021019_51.xml
? GNUe/gnue20021026_52.xml
? GNUe/gnue20021102_53.xml
? GNUe/gnue20021109_54.xml
? GNUe/gnue20021116_55.xml
? GNUe/gnue20021123_56.xml
? GNUe/gnue20021130_57.xml
? GNUe/gnue20021207_58.xml
? GNUe/gnue20021214_59.xml
? GNUe/gnue20021221_60.xml
? GNUe/gnue20021228_61.xml
? GNUe/gnue20030104_62.xml
? GNUe/gnue20030111_63.xml
? GNUe/gnue20030118_64.xml
? GNUe/gnue20030125_65.xml
? GNUe/gnue20030201_66.xml
? GNUe/gnue20030208_67.xml
? GNUe/gnue20030215_68.xml
? GNUe/gnue20030222_69.xml
? GNUe/gnue20030301_70.xml
? GNUe/gnue20030308_71.xml
? GNUe/gnue20030315_72.xml
? GNUe/gnue20030322_73.xml
? GNUe/gnue20030329_74.xml
? GNUe/gnue20030405_75.xml
? GNUe/gnue20030412_76.xml
? GNUe/gnue20030419_77.xml
? GNUe/gnue20030426_78.xml
? GNUe/gnue20030505_79.xml
? GNUe/gnue20030510_80.xml
? GNUe/gnue20030517_81.xml
? GNUe/gnue20030524_82.xml
? GNUe/gnue20030531_83.xml
? GNUe/gnue20030607_84.xml
? GNUe/gnue20030614_85.xml
? GNUe/gnue20030621_86.xml
? GNUe/gnue20030628_87.xml
? GNUe/gnue20030705_88.xml
? GNUe/gnue20030712_89.xml
? GNUe/gnue20030719_90.xml
? GNUe/gnue20030726_91.xml
? GNUe/gnue20030802_92.xml
? GNUe/gnue20030809_93.xml
? GNUe/gnue20030816_94.xml
? GNUe/gnue20030823_95.xml
? GNUe/gnue20031027_97.xml
? GNUe/gnue20031103_98.xml
? GNUe/gnue20031110_99.xml
? GNUe/gnue20031222_101.xml
? GNUe/gnue20031229_102.xml
? GNUe/gnue20040105_103.xml
? GNUe/gnue20040119_105.xml
? GNUe/gnue20040202_106.xml
? GNUe/index.xml
? GNUe/latest.xml
? Makefile
? Makefile.cousinraw
? Makefile.cousinsite
? Makefile.globalvars
? arch/Makefile
? arch/current.xml
? arch/index.xml
? arch/xml.template
? asleep.xml
? author.xml
? authors/Aaron_J._Seigo.html
? authors/Adam_Buchbinder.html
? authors/Alex_Harford.html
? authors/Arturas_Kriukovas.html
? authors/Benedikt_Köhler.html
? authors/Brian_Vincent.html
? authors/Charles_de_Miramon.html
? authors/Chris_Howells.html
? authors/Cris_Flagg.html
? authors/David_Martínez.html
? authors/Eric_Pouech.html
? authors/Eusebio_C_Rufian-Zilbermann.html
? authors/Fabrice_Mous.html
? authors/Henrique_Pinto.html
? authors/Jeff_Waugh.html
? authors/Jens_Müller.html
? authors/John_Guthrie.html
? authors/John_Quirk.html
? authors/Juergen_Appel.html
? authors/KDE_Promo_Team.html
? authors/KDE_Traffic_Team.html
? authors/Leif_Jensen.html
? authors/Mark_Zealey.html
? authors/Martin_Michlmayr.html
? authors/Paul_Emsley.html
? authors/Peter_Eckersley.html
? authors/Peter_Rockai_(mornfall).html
? authors/Peter_Samuelson.html
? authors/Peter_Sullivan.html
? authors/Prashanth_Mundkur.html
? authors/Rob_Kaper.html
? authors/Ronan_O'Sullivan.html
? authors/Russell_Miller.html
? authors/Sam_Phillips.html
? authors/Seth_Cohn.html
? authors/Simon_Law.html
? authors/Steve_Robbins.html
? authors/Timothy_R._Butler.html
? authors/Zack_Brown.html
? authors/Zack_Rusin.html
? bin/news2googleurl-4
? bin/readme
? bin/splitarchives
? bin/splitauthors
? bin/splitquotes
? bin/splittopics
? crash.xml
? debian-hurd/Makefile
? debian-hurd/back-issues.raw
? debian-hurd/dh19990603_1.xml
? debian-hurd/dh19990610_2.xml
? debian-hurd/dh19990617_3.xml
? debian-hurd/dh19990628_4.xml
? debian-hurd/dh19990706_5.xml
? debian-hurd/dh19990713_6.xml
? debian-hurd/dh19990720_7.xml
? debian-hurd/dh19990727_8.xml
? debian-hurd/dh19990803_9.xml
? debian-hurd/dh19990810_10.xml
? debian-hurd/dh19990817_11.xml
? debian-hurd/dh19990824_12.xml
? debian-hurd/dh19990831_13.xml
? debian-hurd/dh19990908_14.xml
? debian-hurd/dh19990914_15.xml
? debian-hurd/dh19990922_16.xml
? debian-hurd/dh19990929_17.xml
? debian-hurd/dh19991006_18.xml
? debian-hurd/dh19991013_19.xml
? debian-hurd/dh19991020_20.xml
? debian-hurd/dh19991027_21.xml
? debian-hurd/dh19991103_22.xml
? debian-hurd/dh19991110_23.xml
? debian-hurd/dh19991117_24.xml
? debian-hurd/dh19991201_25.xml
? debian-hurd/dh19991208_26.xml
? debian-hurd/dh19991215_27.xml
? debian-hurd/dh19991222_28.xml
? debian-hurd/dh19991229_29.xml
? debian-hurd/dh20000105_30.xml
? debian-hurd/dh20000112_31.xml
? debian-hurd/dh20000119_32.xml
? debian-hurd/dh20000126_33.xml
? debian-hurd/dh20000209_34.xml
? debian-hurd/dh20000216_35.xml
? debian-hurd/dh20000223_36.xml
? debian-hurd/dh20000301_37.xml
? debian-hurd/dh20000308_38.xml
? debian-hurd/dh20000315_39.xml
? debian-hurd/dh20000322_40.xml
? debian-hurd/dh20000329_41.xml
? debian-hurd/dh20000405_42.xml
? debian-hurd/dh20000412_43.xml
? debian-hurd/dh20000419_44.xml
? debian-hurd/dh20000426_45.xml
? debian-hurd/dh20000503_46.xml
? debian-hurd/dh20000510_47.xml
? debian-hurd/dh20000517_48.xml
? debian-hurd/dh20000524_49.xml
? debian-hurd/dh20000531_50.xml
? debian-hurd/dh20000607_51.xml
? debian-hurd/dh20000614_52.xml
? debian-hurd/dh20000628_53.xml
? debian-hurd/dh20000712_54.xml
? debian-hurd/dh20000726_55.xml
? debian-hurd/dh20000810_56.xml
? debian-hurd/dh20000816_57.xml
? debian-hurd/dh20000830_58.xml
? debian-hurd/dh20000913_59.xml
? debian-hurd/dh20000927_60.xml
? debian-hurd/dh20001004_61.xml
? debian-hurd/dh20001011_62.xml
? debian-hurd/dh20001018_63.xml
? debian-hurd/dh20001025_64.xml
? debian-hurd/dh20001101_65.xml
? debian-hurd/dh20001108_66.xml
? debian-hurd/dh20001115_67.xml
? debian-hurd/dh20001122_68.xml
? debian-hurd/dh20001129_69.xml
? debian-hurd/dh20001206_70.xml
? debian-hurd/dh20001213_71.xml
? debian-hurd/dh20001220_72.xml
? debian-hurd/dh20001227_73.xml
? debian-hurd/dh20010105_74.xml
? debian-hurd/dh20010110_75.xml
? debian-hurd/dh20010117_76.xml
? debian-hurd/dh20010124_77.xml
? debian-hurd/dh20010131_78.xml
? debian-hurd/dh20010210_79.xml
? debian-hurd/dh20010215_80.xml
? debian-hurd/dh20010222_81.xml
? debian-hurd/dh20010301_82.xml
? debian-hurd/dh20010309_83.xml
? debian-hurd/dh20010314_84.xml
? debian-hurd/dh20010320_85.xml
? debian-hurd/dh20010328_86.xml
? debian-hurd/dh20010420_87.xml
? debian-hurd/dh20010425_88.xml
? debian-hurd/dh20010502_89.xml
? debian-hurd/dh20010508_90.xml
? debian-hurd/dh20010515_91.xml
? debian-hurd/dh20010530_92.xml
? debian-hurd/dh20010611_93.xml
? debian-hurd/dh20010614_94.xml
? debian-hurd/dh20010621_95.xml
? debian-hurd/dh20010627_96.xml
? debian-hurd/dh20010703_97.xml
? debian-hurd/dh20010710_98.xml
? debian-hurd/dh20010717_99.xml
? debian-hurd/dh20010724_100.xml
? debian-hurd/dh20010730_101.xml
? debian-hurd/dh20010807_102.xml
? debian-hurd/dh20010814_103.xml
? debian-hurd/dh20010821_104.xml
? debian-hurd/dh20010828_105.xml
? debian-hurd/dh20010903_106.xml
? debian-hurd/dh20010911_107.xml
? debian-hurd/dh20010918_108.xml
? debian-hurd/dh20010925_109.xml
? debian-hurd/dh20011002_110.xml
? debian-hurd/dh20011009_111.xml
? debian-hurd/dh20011023_112.xml
? debian-hurd/dh20011030_113.xml
? debian-hurd/dh20011106_114.xml
? debian-hurd/dh20020319_115.xml
? debian-hurd/dh20020326_116.xml
? debian-hurd/dh20020409_117.xml
? debian-hurd/dh20020416_118.xml
? debian-hurd/dh20020618_119.xml
? debian-hurd/dh20020730_120.xml
? debian-hurd/hurdtalk1
? debian-hurd/hurdtalk1.1
? debian-hurd/hurdtalk1.2
? debian-hurd/hurdtalk1.3
? debian-hurd/hurdtalk1.4
? debian-hurd/index.xml
? debian-hurd/latest.xml
? debian-hurd/topics.pl
? debian-hurd/xml.template
? debian/Makefile
? debian/back-issues.raw
? debian/dd20000907_1.xml
? debian/dd20000914_2.xml
? debian/dd20000921_3.xml
? debian/dd20000928_4.xml
? debian/dd20001005_5.xml
? debian/dd20001012_6.xml
? debian/dd20001019_7.xml
? debian/dd20001026_8.xml
? debian/dd20001102_9.xml
? debian/dd20001109_10.xml
? debian/dd20001116_11.xml
? debian/dd20001123_12.xml
? debian/dd20001130_13.xml
? debian/dd20001214_14.xml
? debian/dd20001222_15.xml
? debian/dd20001229_16.xml
? debian/dd20010105_17.xml
? debian/dd20010112_18.xml
? debian/dd20010118_19.xml
? debian/dd20010125_20.xml
? debian/dd20010201_21.xml
? debian/dd20010210_22.xml
? debian/dd20010216_23.xml
? debian/dd20010222_24.xml
? debian/dd20010302_25.xml
? debian/dd20010312_26.xml
? debian/dd20010316_27.xml
? debian/dd20010328_28.xml
? debian/dd20020102_29.xml
? debian/index.xml
? debian/latest.txt
? debian/latest.xml
? debian/trans/german/Makefile
? debian/trans/german/Makefile.encoding
? debian/trans/german/dd20000907_1.xml
? debian/trans/german/dd20000914_2.xml
? debian/trans/german/index.xml.bak
? debian/trans/german/latest.txt
? debian/trans/german/latest.xml
? devel.xml
? donations.xml
? editor.xml
? favicon.ico
? gimp/Makefile
? gimp/back-issues.raw
? gimp/gd19990613_1.xml
? gimp/gd19990620_2.xml
? gimp/gd19990627_3.xml
? gimp/gd19990704_4.xml
? gimp/gd19990809_5.xml
? gimp/gd19990820_6.xml
? gimp/gd20000101_7.xml
? gimp/gd20000107_8.xml
? gimp/gd20000114_9.xml
? gimp/gd20000121_10.xml
? gimp/gd20000128_11.xml
? gimp/gd20000204_12.xml
? gimp/gd20000211_13.xml
? gimp/gd20000218_14.xml
? gimp/gd20000224_15.xml
? gimp/gd20000302_16.xml
? gimp/gd20000310_17.xml
? gimp/gd20000324_18.xml
? gimp/gd20000331_19.xml
? gimp/gd20000506_20.xml
? gimp/gd20000528_21.xml
? gimp/gd20000605_22.xml
? gimp/gd20000619_23.xml
? gimp/gd20000710_24.xml
? gimp/gd20001231_25.xml
? gimp/gd20010108_26.xml
? gimp/gd20010115_27.xml
? gimp/gd20010122_28.xml
? gimp/gd20010129_29.xml
? gimp/gd20010205_30.xml
? gimp/gd20010212_31.xml
? gimp/gd20010220_32.xml
? gimp/gd20010226_33.xml
? gimp/gd20010305_34.xml
? gimp/gd20010312_35.xml
? gimp/gd20010319_36.xml
? gimp/gd20010402_37.xml
? gimp/gd20010406_38.xml
? gimp/gd20010416_39.xml
? gimp/gd20010502_40.xml
? gimp/gd20010507_41.xml
? gimp/gd20010507_42.xml
? gimp/gd20010522_43.xml
? gimp/gd20010615_44.xml
? gimp/index.xml
? gimp/kde
? gimp/latest.xml
? git/Makefile
? git/back-issues.raw
? git/current.xml
? git/gt20050502_1.xml
? git/index.xml
? git/latest.xml
? git/topics.pl
? git/topics.raw
? git/xml.template
? gpl.txt
? help.xml
? index.xml
? irc.xml
? kde/Makefile
? kde/back-issues.raw
? kde/index.xml
? kde/kde20010310_1.xml
? kde/kde20010316_2.xml
? kde/kde20010324_3.xml
? kde/kde20010331_4.xml
? kde/kde20010406_5.xml
? kde/kde20010413_6.xml
? kde/kde20010420_7.xml
? kde/kde20010427_8.xml
? kde/kde20010511_9.xml
? kde/kde20010517_10.xml
? kde/kde20010525_11.xml
? kde/kde20010602_12.xml
? kde/kde20010608_13.xml
? kde/kde20010615_14.xml
? kde/kde20010622_15.xml
? kde/kde20010629_16.xml
? kde/kde20010713_17.xml
? kde/kde20010720_18.xml
? kde/kde20010803_19.xml
? kde/kde20010810_20.xml
? kde/kde20010824_21.xml
? kde/kde20011018_22.xml
? kde/kde20011026_23.xml
? kde/kde20011102_24.xml
? kde/kde20011109_25.xml
? kde/kde20011123_26.xml
? kde/kde20011130_27.xml
? kde/kde20011207_28.xml
? kde/kde20020104_29.xml
? kde/kde20020111_30.xml
? kde/kde20020118_31.xml
? kde/kde20020215_32.xml
? kde/kde20020222_33.xml
? kde/kde20020301_34.xml
? kde/kde20020308_35.xml
? kde/kde20020315_36.xml
? kde/kde20020522_37.xml
? kde/kde20020605_38.xml
? kde/kde20020619_39.xml
? kde/kde20020710_40.xml
? kde/kde20020724_41.xml
? kde/kde20020731_42.xml
? kde/kde20020821_43.xml
? kde/kde20021009_44.xml
? kde/kde20021028_45.xml
? kde/kde20021126_46.xml
? kde/kde20030419_47.xml
? kde/kde20030426_48.xml
? kde/kde20030504_49.xml
? kde/kde20030511_50.xml
? kde/kde20030517_51.xml
? kde/kde20030525_52.xml
? kde/kde20030602_53.xml
? kde/kde20030608_54.xml
? kde/kde20030618_55.xml
? kde/kde20030622_56.xml
? kde/kde20030702_57.xml
? kde/kde20030716_58.xml
? kde/kde20030722_59.xml
? kde/kde20030726_60.xml
? kde/kde20030811_61.xml
? kde/kde20030823_62.xml
? kde/kde20030901_63.xml
? kde/kde20030907_64.xml
? kde/kde20030929_65.xml
? kde/kde20031004_66.xml
? kde/kde20031109_67.xml
? kde/kde20031116_68.xml
? kde/kde20031130_69.xml
? kde/kde20031207_70.xml
? kde/kde20031214_71.xml
? kde/kde20031222_72.xml
? kde/kde20031231_73.xml
? kde/kde20040122_74.xml
? kde/kde20040227_75.xml
? kde/kde20040416_76.xml
? kde/latest.xml
? kde/sample.xml
? kde/trans/french/Makefile
? kde/trans/french/Makefile.encoding
? kde/trans/french/index.xml.bak
? kde/trans/french/kde20011018_22.xml
? kde/trans/french/kde20011026_23.xml
? kde/trans/french/kde20011102_24.xml
? kde/trans/french/kde20011109_25.xml
? kde/trans/french/kde20011123_26.xml
? kde/trans/french/kde20011130_27.xml
? kde/trans/french/kde20011207_28.xml
? kde/trans/french/kde20020104_29.xml
? kde/trans/french/kde20020111_30.xml
? kde/trans/french/kde20020118_31.xml
? kde/trans/french/kde20020215_32.xml
? kde/trans/french/kde20020308_35.xml
? kde/trans/french/kde20020522_37.xml
? kde/trans/french/kde20020619_39.xml
? kde/trans/french/kde20020710_40.xml
? kde/trans/french/kde20020724_41.xml
? kde/trans/french/kde20020731_42.xml
? kde/trans/french/kde20020821_43.xml
? kde/trans/french/kde20021009_44.xml
? kde/trans/french/kde20021028_45.xml
? kde/trans/french/kde20021126_46.xml
? kde/trans/french/latest.txt
? kde/trans/french/latest.xml
? kde/trans/german/Makefile
? kde/trans/german/Makefile.encoding
? kde/trans/german/kde20020522_37.xml
? kde/trans/german/kde20020522_37.xml.old
? kde/trans/german/kde20020605_38.xml
? kde/trans/german/latest.txt
? kde/trans/german/latest.xml
? kde/trans/spanish/Makefile
? kde/trans/spanish/Makefile.encoding
? kde/trans/spanish/index.xml.bak
? kde/trans/spanish/kde20020118_31.xml
? kde/trans/spanish/kde20020215_32.xml
? kde/trans/spanish/kde20020222_33.xml
? kde/trans/spanish/kde20020605_38.xml
? kde/trans/spanish/kde20020619_39.xml
? kde/trans/spanish/kde20020710_40.xml
? kde/trans/spanish/latest.txt
? kde/trans/spanish/latest.xml
? kernel-traffic/stats/Makefile
? kernel-traffic/stats/kt20050212_296_stats.xml
? kernel-traffic/stats/kt20050219_297_stats.xml
? kernel-traffic/stats/kt20050306_298_stats.xml
? kernel-traffic/stats/kt20050306_299_stats.xml
? kernel-traffic/stats/kt20050329_300_stats.xml
? kernel-traffic/stats/kt20050402_301_stats.xml
? kernel-traffic/stats/kt20050402_302_stats.xml
? kernel-traffic/stats/kt20050403_303_stats.xml
? kernel-traffic/stats/kt20050403_304_stats.xml
? kernel-traffic/stats/kt20050404_305_stats.xml
? kernel-traffic/stats/kt20050411_306_stats.xml
? kernel-traffic/stats/kt20050426_307_stats.xml
? kernel-traffic/stats/kt20050428_308_stats.xml
? kernel-traffic/stats/kt20050604_311_stats.xml
? kernel-traffic/trans/czech/Makefile
? kernel-traffic/trans/czech/Makefile.encoding
? kernel-traffic/trans/czech/index.xml
? kernel-traffic/trans/czech/kt20000110_50.xml.bak
? kernel-traffic/trans/czech/kt20000117_51.xml.bak
? kernel-traffic/trans/czech/kt20000124_52.xml.bak
? kernel-traffic/trans/czech/kt20000207_53.xml.bak
? kernel-traffic/trans/czech/kt20000214_54.xml.bak
? kernel-traffic/trans/czech/kt20000221_55.xml.bak
? kernel-traffic/trans/czech/kt20000228_56.xml.bak
? kernel-traffic/trans/czech/kt20000306_57.xml.bak
? kernel-traffic/trans/czech/kt20000313_58.xml.bak
? kernel-traffic/trans/czech/kt20000320_59.xml.bak
? kernel-traffic/trans/czech/kt20000327_60.xml.bak
? kernel-traffic/trans/czech/kt20000403_61.xml.bak
? kernel-traffic/trans/czech/kt20000410_62.xml.bak
? kernel-traffic/trans/czech/kt20000417_63.xml.bak
? kernel-traffic/trans/czech/kt20000424_64.xml.bak
? kernel-traffic/trans/czech/kt20000501_65.xml.bak
? kernel-traffic/trans/czech/kt20000507_66.xml.bak
? kernel-traffic/trans/czech/kt20000515_67.xml.bak
? kernel-traffic/trans/czech/kt20000522_68.xml.bak
? kernel-traffic/trans/czech/kt20000529_69.xml.bak
? kernel-traffic/trans/czech/kt20000605_70.xml.bak
? kernel-traffic/trans/czech/kt20000612_71.xml.bak
? kernel-traffic/trans/czech/kt20000619_72.xml.bak
? kernel-traffic/trans/czech/kt20000626_73.xml.bak
? kernel-traffic/trans/czech/kt20000703_74.xml.bak
? kernel-traffic/trans/czech/kt20000710_75.xml.bak
? kernel-traffic/trans/czech/kt20000717_76.xml.bak
? kernel-traffic/trans/czech/kt20000724_77.xml.bak
? kernel-traffic/trans/czech/kt20000731_78.xml.bak
? kernel-traffic/trans/czech/kt20000807_79.xml.bak
? kernel-traffic/trans/czech/kt20000814_80.xml.bak
? kernel-traffic/trans/czech/kt20000821_81.xml.bak
? kernel-traffic/trans/czech/kt20000828_82.xml.bak
? kernel-traffic/trans/czech/kt20000904_83.xml.bak
? kernel-traffic/trans/czech/kt20000911_84.xml.bak
? kernel-traffic/trans/czech/kt20000918_85.xml.bak
? kernel-traffic/trans/czech/kt20000925_86.xml.bak
? kernel-traffic/trans/czech/kt20001002_87.xml.bak
? kernel-traffic/trans/czech/kt20001010_88.xml.bak
? kernel-traffic/trans/czech/kt20001016_89.xml.bak
? kernel-traffic/trans/czech/kt20001023_90.xml.bak
? kernel-traffic/trans/czech/kt20001030_91.xml.bak
? kernel-traffic/trans/czech/kt20001106_92.xml.bak
? kernel-traffic/trans/czech/kt20001113_93.xml.bak
? kernel-traffic/trans/czech/kt20001120_94.xml.bak
? kernel-traffic/trans/czech/kt20001127_95.xml.bak
? kernel-traffic/trans/czech/kt20001204_96.xml.bak
? kernel-traffic/trans/czech/kt20001211_97.xml.bak
? kernel-traffic/trans/czech/kt20001218_98.xml.bak
? kernel-traffic/trans/czech/kt20001225_99.xml.bak
? kernel-traffic/trans/czech/kt20010101_100.xml.bak
? kernel-traffic/trans/czech/kt20010108_101.xml.bak
? kernel-traffic/trans/czech/kt20010112_102.xml.bak
? kernel-traffic/trans/czech/kt20010119_103.xml.bak
? kernel-traffic/trans/czech/kt20010126_104.xml.bak
? kernel-traffic/trans/czech/kt20010202_105.xml.bak
? kernel-traffic/trans/czech/kt20010209_106.xml.bak
? kernel-traffic/trans/czech/kt20010216_107.xml.bak
? kernel-traffic/trans/czech/kt20010223_108.xml.bak
? kernel-traffic/trans/czech/kt20010302_109.xml.bak
? kernel-traffic/trans/czech/kt20010309_110.xml.bak
? kernel-traffic/trans/czech/kt20010316_111.xml.bak
? kernel-traffic/trans/czech/kt20010323_112.xml.bak
? kernel-traffic/trans/czech/kt20010330_113.xml.bak
? kernel-traffic/trans/czech/kt20010416_114.xml.bak
? kernel-traffic/trans/czech/kt20010917_133.xml.bak
? kernel-traffic/trans/czech/kt20020128_152.xml.bak
? kernel-traffic/trans/czech/kt20020211_153.xml.bak
? kernel-traffic/trans/czech/kt20020218_154.xml.bak
? kernel-traffic/trans/czech/kt20020225_155.xml.bak
? kernel-traffic/trans/czech/kt20020304_156.xml.bak
? kernel-traffic/trans/czech/kt20020311_157.xml.bak
? kernel-traffic/trans/czech/kt20020318_158.xml.bak
? kernel-traffic/trans/czech/kt20020325_159.xml.bak
? kernel-traffic/trans/czech/kt20020401_160.xml.bak
? kernel-traffic/trans/czech/kt20020407_161.xml.bak
? kernel-traffic/trans/czech/kt20020415_162.xml.bak
? kernel-traffic/trans/czech/kt20020422_163.xml.bak
? kernel-traffic/trans/czech/kt20020429_164.xml.bak
? kernel-traffic/trans/czech/kt20020506_165.xml.bak
? kernel-traffic/trans/czech/kt20020513_166.xml.bak
? kernel-traffic/trans/czech/kt20020520_167.xml.bak
? kernel-traffic/trans/czech/kt20020527_168.xml.bak
? kernel-traffic/trans/czech/kt20020603_169.xml.bak
? kernel-traffic/trans/czech/kt20020609_170.xml.bak
? kernel-traffic/trans/czech/kt20020617_171.xml.bak
? kernel-traffic/trans/czech/kt20020624_172.xml.bak
? kernel-traffic/trans/czech/kt20020708_174.xml.bak
? kernel-traffic/trans/czech/kt20020715_175.xml.bak
? kernel-traffic/trans/czech/kt20020722_176.xml.bak
? kernel-traffic/trans/czech/kt20020805_178.xml.bak
? kernel-traffic/trans/czech/kt20020812_179.xml.bak
? kernel-traffic/trans/czech/kt20020819_180.xml.bak
? kernel-traffic/trans/czech/kt20020826_181.xml.bak
? kernel-traffic/trans/czech/kt20020902_182.xml.bak
? kernel-traffic/trans/czech/kt20020909_183.xml.bak
? kernel-traffic/trans/czech/kt20020916_184.xml.bak
? kernel-traffic/trans/czech/kt20020923_185.xml.bak
? kernel-traffic/trans/czech/kt20020930_186.xml.bak
? kernel-traffic/trans/czech/kt20021007_187.xml.bak
? kernel-traffic/trans/czech/kt20021014_188.xml.bak
? kernel-traffic/trans/czech/kt20021021_189.xml.bak
? kernel-traffic/trans/czech/kt20021028_190.xml.bak
? kernel-traffic/trans/czech/kt20021111_191.xml.bak
? kernel-traffic/trans/czech/kt20021118_192.xml.bak
? kernel-traffic/trans/czech/kt20021125_193.xml.bak
? kernel-traffic/trans/czech/kt20021202_194.xml.bak
? kernel-traffic/trans/czech/kt20021209_195.xml.bak
? kernel-traffic/trans/czech/kt20021216_196.xml.bak
? kernel-traffic/trans/czech/kt20021223_197.xml.bak
? kernel-traffic/trans/czech/kt20021230_198.xml.bak
? kernel-traffic/trans/czech/kt20030106_199.xml.bak
? kernel-traffic/trans/czech/kt20030113_200.xml.bak
? kernel-traffic/trans/czech/kt20030117_201.xml.bak
? kernel-traffic/trans/czech/kt20030124_202.xml.bak
? kernel-traffic/trans/czech/kt20030131_203.xml.bak
? kernel-traffic/trans/czech/kt20030209_204.xml.bak
? kernel-traffic/trans/czech/kt20030216_205.xml.bak
? kernel-traffic/trans/czech/kt20030223_206.xml.bak
? kernel-traffic/trans/czech/kt20030302_207.xml.bak
? kernel-traffic/trans/czech/kt20030309_208.xml.bak
? kernel-traffic/trans/czech/kt20030316_209.xml.bak
? kernel-traffic/trans/czech/kt20030323_210.xml.bak
? kernel-traffic/trans/czech/kt20030330_211.xml.bak
? kernel-traffic/trans/czech/kt20030406_212.xml.bak
? kernel-traffic/trans/czech/kt20030413_213.xml.bak
? kernel-traffic/trans/czech/kt20030428_214.xml.bak
? kernel-traffic/trans/czech/kt20030509_215.xml.bak
? kernel-traffic/trans/czech/kt20030520_216.xml.bak
? kernel-traffic/trans/czech/kt20030523_217.xml.bak
? kernel-traffic/trans/czech/kt20030607_218.xml.bak
? kernel-traffic/trans/czech/kt20030616_219.xml.bak
? kernel-traffic/trans/czech/kt20030708_221.xml
? kernel-traffic/trans/czech/kt20030710_222.xml
? kernel-traffic/trans/czech/kt20030720_223.xml
? kernel-traffic/trans/czech/kt20030730_224.xml
? kernel-traffic/trans/czech/kt20030731_225.xml
? kernel-traffic/trans/czech/kt20030805_226.xml.bak
? kernel-traffic/trans/czech/kt20030811_227.xml
? kernel-traffic/trans/czech/kt20030817_228.xml
? kernel-traffic/trans/czech/kt20030908_229.xml
? kernel-traffic/trans/czech/kt20030909_230.xml
? kernel-traffic/trans/czech/kt20030910_231.xml
? kernel-traffic/trans/czech/kt20030920_232.xml
? kernel-traffic/trans/czech/kt20031004_233.xml
? kernel-traffic/trans/czech/kt20031006_234.xml
? kernel-traffic/trans/czech/kt20031024_235.xml
? kernel-traffic/trans/czech/kt20031026_236.xml
? kernel-traffic/trans/czech/kt20031026_237.xml
? kernel-traffic/trans/czech/kt20031027_238.xml
? kernel-traffic/trans/czech/kt20031101_239.xml
? kernel-traffic/trans/czech/kt20031109_240.xml
? kernel-traffic/trans/czech/kt20031116_241.xml
? kernel-traffic/trans/czech/kt20031124_242.xml
? kernel-traffic/trans/czech/kt20031201_243.xml
? kernel-traffic/trans/czech/kt20031208_244.xml
? kernel-traffic/trans/czech/kt20031214_245.xml
? kernel-traffic/trans/czech/kt20031226_246.xml
? kernel-traffic/trans/czech/kt20031231_247.xml
? kernel-traffic/trans/czech/kt20040120_248.xml
? kernel-traffic/trans/czech/kt20040127_249.xml
This is a much larger list of over 700 files.
Be well,
Zack
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: cg-init bug
From: Radoslaw Szkodzinski @ 2005-06-05 17:59 UTC (permalink / raw)
To: Zack Brown; +Cc: pasky, git
In-Reply-To: <20050605162739.GB15291@tumblerings.org>
Zack Brown wrote:
>But shouldn't cg-init take care of that for me automatically when I create the
>repo?
>
>Be well,
>Zack
>
>
It should, it's most probably a bug...
Maybe you don't have read permission on some of the files?
I can't explain it in any other way.
AstralStorm
^ permalink raw reply
* Re: SSH pull problems
From: Radoslaw Szkodzinski @ 2005-06-05 18:02 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0506051336440.30848-100000@iabervon.org>
Daniel Barkalow wrote:
>On Sat, 4 Jun 2005, Radoslaw Szkodzinski wrote:
>
>
>
>>I had some problems today with git+ssh protocol.
>>First, when using cg-clone, it couldn't execute cg-rpush, although it's
>>there in /usr/local.
>>Maybe that has something to do with that being added to the path in
>>/etc/profile.
>>
>>
>
>I haven't used recent Cogito, so I'm not sure, but it might actually want
>git-rpush rather than cg-rpush? Or it might be a permissions issue?
>
>
>
Make that git-rpush, I was writing from my memory, and it couldn't find
it, as in "Command not found".
It's available for all to exec, in /usr/local.
>>Second, I don't know how to specify the port number,
>>the typical notation of git+ssh://xyz:port/repo didn't work.
>>
>>
>
>I haven't made it understand port numbers yet; it should be pretty easy,
>though, if you want to do it. You'd probably have a better chance of
>getting it right than I would, if you've got an SSH server on a
>non-default port to test against. Just parse out the part of "host" after
>the : and make it a "-p" option in the execlp in rsh.c.
>
>
>
That's not a problem, I'll get to it in some short time and post a patch.
AstralStorm
^ permalink raw reply
* Re: [PATCH] git-daemon server
From: Linus Torvalds @ 2005-06-05 18:11 UTC (permalink / raw)
To: Jason McMullan; +Cc: Daniel Barkalow, git
In-Reply-To: <1117990178.10424.15.camel@port.evillabs.net>
On Sun, 5 Jun 2005, Jason McMullan wrote:
>
> On Fri, 2005-06-03 at 14:59 -0700, Linus Torvalds wrote:
> > Me, I want to have a fairly simple script that does the equivalent of what
> > I do now for pushing:
> >
> > rsync -av --delete --exclude-from=.exclude .git/ master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >
> > except I'd want it to do the locking and the "only accept trivial pushes"
> > stuff (ie no merging, just a pure update).
>
>
> $ GITCONNECTION="--tcp ...."
Nope. I'm not going to run untrusted deamons of my own on master.
I'm serious about the "ssh or nothing" thing. Anything but a direct ssh
conection is simply not an option.
Linus
^ permalink raw reply
* Re: cg-init bug
From: Petr Baudis @ 2005-06-05 18:10 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20050605175634.GB6890@tumblerings.org>
Dear diary, on Sun, Jun 05, 2005 at 07:56:34PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> Depending on how I check, I get very different lists. I'll include both in this email.
>
> If I do the 'cg-init' on the full source.cogito directory, then do a 'cg-clone'
> into a new source.cogtst directory, here is the result of a comparison:
Hmm. That's very strange, I can't see what could be the problem. If you
try cg-init multiple times, do you always get the same list of files
missed out? Can you spot any error messages while doing cg-init?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: cg-init bug -- identified
From: Zack Brown @ 2005-06-05 18:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050605181042.GH17462@pasky.ji.cz>
On Sun, Jun 05, 2005 at 08:10:42PM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Jun 05, 2005 at 07:56:34PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > Depending on how I check, I get very different lists. I'll include both in this email.
> >
> > If I do the 'cg-init' on the full source.cogito directory, then do a 'cg-clone'
> > into a new source.cogtst directory, here is the result of a comparison:
>
> Hmm. That's very strange, I can't see what could be the problem. If you
> try cg-init multiple times, do you always get the same list of files
> missed out? Can you spot any error messages while doing cg-init?
I figured it out.
I made a temporary copy of the directory, and kept doing
$ rm -rf .git
$ rm somerandomfileordir
$ cg-init
$ cg-status
It turned out one of my files had a "'" in the name, i.e.:
$ ls
Zack's_file
$
I removed it, and all of a sudden cg-init worked perfectly.
Is that a Cogito bug? I would expect git to handle any filename the filesystem
itself can handle.
Be well,
Zack
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: SSH pull problems
From: Radoslaw Szkodzinski @ 2005-06-05 18:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050605175041.GG17462@pasky.ji.cz>
Petr Baudis wrote:
>If you are staying at the Cogito's tip, there was an incompatible
>protocol change introduced recently, so make sure you have the same
>Cogito version on both sides.
>
>
I've updated both at the same time, just before the access. So this is
impossible.
AstralStorm
^ permalink raw reply
* Re: cg-init bug -- identified
From: Tommy M. McGuire @ 2005-06-05 18:43 UTC (permalink / raw)
To: Zack Brown; +Cc: Petr Baudis, git
In-Reply-To: <20050605182912.GC6890@tumblerings.org>
On Sun, Jun 05, 2005 at 11:29:12AM -0700, Zack Brown wrote:
> It turned out one of my files had a "'" in the name, i.e.:
Now this is a neat one.
[mcguire@immobile cgtest]$ sh -x cg-init
[... Normal behavior ...]
+ touch .git/refs/heads/master
+ '[' '' ']'
+ git-read-tree
+ find bar baz foo 'foo'\''prime' '(' -type f -o -type l ')' -print0
+ xargs -0r cg-add
Adding file bar
Adding file baz/1
Adding file baz/0
Adding file foo
Adding file foo'prime
xargs: unmatched single quote
+ cg-commit -C '-mInitial commit' -E
The error is the second-to-last line. It partially succeeded originally
because xargs broke off and handled parts of the input before reaching
the single quote.
[By the way, hello! I've just recently started climbing the git
learning curve, and it's nice to see something I recognize. :-)]
--
Tommy McGuire
^ permalink raw reply
* Re: cg-init bug -- identified
From: Tommy M. McGuire @ 2005-06-05 19:09 UTC (permalink / raw)
To: Tommy M. McGuire; +Cc: Zack Brown, Petr Baudis, git
In-Reply-To: <20050605184341.GA21345@immutable.crsr.net>
On Sun, Jun 05, 2005 at 01:43:41PM -0500, Tommy M. McGuire wrote:
> Adding file foo'prime
> xargs: unmatched single quote
> + cg-commit -C '-mInitial commit' -E
>
> The error is the second-to-last line. It partially succeeded originally
> because xargs broke off and handled parts of the input before reaching
> the single quote.
The bug is in cg-add, which doesn't use -print0 and -0.
--
Tommy McGuire
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -20,9 +20,9 @@ USAGE="cg-add FILE..."
[ "$1" ] || usage
TMPFILE=$(mktemp -t gitadd.XXXXXX)
-find "$@" -type f > $TMPFILE || die "not all files exist, nothing added"
+find "$@" -type f -print0 > $TMPFILE || die "not all files exist, nothing added"
-cat $TMPFILE | awk '{print "Adding file " $0}'
-cat $TMPFILE | xargs git-update-cache --add --
+cat $TMPFILE | xargs -0l1 echo "Adding file "
+cat $TMPFILE | xargs -0 git-update-cache --add --
rm $TMPFILE
^ permalink raw reply
* [PATCH] Make cg-add use xargs -0
From: Dan Holmsand @ 2005-06-05 19:15 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <20050605184341.GA21345@immutable.crsr.net>
[-- Attachment #1: Type: text/plain, Size: 141 bytes --]
Make cg-add use xargs -0, to avoid failure on files with
quotes of all kinds, spaces, etc.
Signed-off-by: Dan Holmsand <holmsand@gmail.com>
[-- Attachment #2: cg-add.patch.txt --]
[-- Type: text/plain, Size: 686 bytes --]
cg-add | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -19,10 +19,13 @@ USAGE="cg-add FILE..."
[ "$1" ] || usage
-TMPFILE=$(mktemp -t gitadd.XXXXXX)
-find "$@" -type f > $TMPFILE || die "not all files exist, nothing added"
+TMPFILE=$(mktemp -t gitadd.XXXXXX) || exit 1
+find "$@" -type f -print0 > $TMPFILE || {
+ die "not all files exist, nothing added"
+ rm $TMPFILE
+}
-cat $TMPFILE | awk '{print "Adding file " $0}'
-cat $TMPFILE | xargs git-update-cache --add --
+cat $TMPFILE | tr \\0 \\n | awk '{print "Adding file " $0}'
+cat $TMPFILE | xargs -0r git-update-cache --add --
rm $TMPFILE
^ permalink raw reply
* [PATCH] Re: cg-init bug -- identified
From: Tommy M. McGuire @ 2005-06-05 19:22 UTC (permalink / raw)
To: Tommy M. McGuire; +Cc: git
In-Reply-To: <20050605190938.GB21345@immutable.crsr.net>
[-- Attachment #1: Type: text/plain, Size: 125 bytes --]
Ok, so cg-mkpatch is nifty. (Note: slightly diferent patch to avoid
extra space when listing the files.)
--
Tommy McGuire
[-- Attachment #2: cg-add.patch --]
[-- Type: text/plain, Size: 985 bytes --]
Use -print0 with find and -0 with xargs to avoid problems with quotes,
etc., in filenames.
---
commit b106726cd681a9cb26343191afc74ccca5d4e351
tree a674424eddc66e19cf806113c70fd80e81879dd1
parent ac9f200795352b9330dcf3c18298ce3b738c7024
author Tommy M. McGuire <mcguire@crsr.net> Sun, 05 Jun 2005 14:17:37 -0500
committer Tommy M. McGuire <mcguire@crsr.net> Sun, 05 Jun 2005 14:17:37 -0500
cg-add | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -20,9 +20,9 @@ USAGE="cg-add FILE..."
[ "$1" ] || usage
TMPFILE=$(mktemp -t gitadd.XXXXXX)
-find "$@" -type f > $TMPFILE || die "not all files exist, nothing added"
+find "$@" -type f -print0 > $TMPFILE || die "not all files exist, nothing added"
-cat $TMPFILE | awk '{print "Adding file " $0}'
-cat $TMPFILE | xargs git-update-cache --add --
+cat $TMPFILE | xargs -0l1 echo "Adding file"
+cat $TMPFILE | xargs -0 git-update-cache --add --
rm $TMPFILE
^ permalink raw reply
* Re: [PATCH] pull: gracefully recover from delta retrieval failure.
From: Daniel Barkalow @ 2005-06-05 20:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jason McMullan, Linus Torvalds, git
In-Reply-To: <7vekbg3de7.fsf@assigned-by-dhcp.cox.net>
On Sun, 5 Jun 2005, Junio C Hamano wrote:
> >>>>> "JM" == Jason McMullan <jason.mcmullan@timesys.com> writes:
>
> JM> Sorry about being a pest, but this worries me. Please assuage my fears.
>
> Earlier I said I suspected that the original code mishandled
> recovery from a botched tree/commit dependent transfer, but that
> was not the case. The last test in the new test script I added
> in the patch you are responding to covers that case.
It does the O(history) method for correctness at the expense of
efficiency; my hope is that a bit of caching can fix the efficiency issue
as well. So the question is not really "not safe" as "slow". Of course, it
takes a while for this to become an issue, given the relationship of
remote access latency to local access bandwidth. That is, you need a
really big history and to be getting very little new data before you'll
complain.
> JM> (Or, if you'd like, I can rework pull.c to use the
> JM> verification-before-store technique I used in my git-daemon patch, so
> JM> all the *-pull mechanisms will be 'safe')
>
> I would appreciate the offer. I, however, would have to warn
> you that the "problem" lies in the way the current pull
> structure devides responsibility between the pull.c and transfer
> backends. The pull.c implements the dependency logic, and
> transfer backends are to populate the database while being
> oblivious of that logic. From the purist point of view (I am
> sympathetic to your "place only the verified objects in the
> database" principle), I am not entirely happy with that
> division, but at the same time I understand why it is done that
> way and even like it from practical standpoint.
At one point I'd written a patch that split out the tmpfile usage of
write_sha1_file(), made the filenames predictable, and used it for
everything that writes those files. It had an "open" part and a
"close" part (where the close also moved the file into place). This would
give the code better atomicity and protect against races between reading
and validation. On the other hand, there's no reason to use an anonymous
temp file; just <filename>.partial or similar (with the proper open
flags) would be sufficient and easier to clean or commit. Note that we
want to support /tmp and the object directory being on different
filesystems, also. (And all the open and place logic is nicely wrapped up
in sha1_file.c)
Aside from the question of whether we want to insist that the object
database only includes objects such that everything reachable is also
present, we certainly want to only include objects which we have
completely fetched, which are generically well-formed, and which have the
advertized hash, and having there never be an unvalidated file at the
filename would be good.
By this reasoning, a file should only be renamed after all of the delta
requirements are satisfied, but before tree and commit requirements are
satisfied. We certainly aren't going to have much use for files whose
contents we cannot get. This means that we'd like to have multiple
unplaced files, but we don't need to read the contents of an unplaced
file.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: cg-init bug -- identified
From: Petr Baudis @ 2005-06-05 20:19 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20050605182912.GC6890@tumblerings.org>
Dear diary, on Sun, Jun 05, 2005 at 08:29:12PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> I figured it out.
>
> I made a temporary copy of the directory, and kept doing
>
> $ rm -rf .git
> $ rm somerandomfileordir
> $ cg-init
> $ cg-status
>
> It turned out one of my files had a "'" in the name, i.e.:
>
> $ ls
> Zack's_file
> $
>
> I removed it, and all of a sudden cg-init worked perfectly.
>
> Is that a Cogito bug? I would expect git to handle any filename the filesystem
> itself can handle.
Could you check with the latest Cogito, please?
(88467971134efddf66793ba44c4ee1ffc7573a0a)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [COGITO PATCH] Small, simple and obvious cleanups (are they wanted at this stage?)
From: Petr Baudis @ 2005-06-05 20:25 UTC (permalink / raw)
To: C. Cooke; +Cc: git
In-Reply-To: <429E0B08.5040603@gkhs.net>
Dear diary, on Wed, Jun 01, 2005 at 09:22:48PM CEST, I got a letter
where "C. Cooke" <ccooke@gkhs.net> told me that...
> This is a simple example - giving a nice error if you're in the wrong
> directory.
>
> Is this sort of patch wanted? If so, I'm sure I can spare the time to
> look into some polishing.
Of course they are wanted. Thanks, applied.
> ------------------------------
> Add some sanity checking - does $_git exist, and is it writable.
>
> ---
> commit 06afdeefff9fe02cd2a67f223e687646cacf736f
> tree cebc55541b89b5370335fc172814feb48456dc85
> parent 20e473c9afd8b5d2d549b0e7881473600beb9c37
> author C. Cooke <ccooke@slab.earth.gkhs.net> Wed, 01 Jun 2005 20:03:46 +0100
> committer C. Cooke <ccooke@slab.earth.gkhs.net> Wed, 01 Jun 2005
> 20:03:46 +0100
>
> cg-Xnormid | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/cg-Xnormid b/cg-Xnormid
> --- a/cg-Xnormid
> +++ b/cg-Xnormid
> @@ -16,6 +16,15 @@
>
> id="$1"
>
> +# A little sanity checking.
> +if [ ! -d "$_git" ]; then
> + echo "There is no Git repository here ($_git not found)" >&2
> + exit 1
> +elif [ ! -r "$_git" ] || [ ! -x "$_git" ]; then
> + echo "You do not have permission to access this git repository" >&2
> + exit 1
> +fi
> +
> if [ ! "$id" ] || [ "$id" = "this" ] || [ "$id" = "HEAD" ]; then
> read id < "$_git/HEAD"
I removed the -r check. What is it good for?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ 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