* [PATCH] git-pasky: Add .gitrc directory to allow command defaults like with .cvsrc
From: Fabian Franz @ 2005-04-22 16:28 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
one thing I liked about CVS was its way to configure default parameters for
commands.
And as I really like the colored log output, I wanted it as default.
While .cvsrc parsing would be quite expensive, using a directory + files
should be fairly cheap and result just in one additional stat-call.
So I added "-c" to ~/.gitrc/log and some code to parse this.
Index: git
===================================================================
- --- 0a9ee5a4d947b998a7ce489242800b39f98eeee5/git (mode:100755
sha1:39969debd59ed51c57973c819cdcc3ca8a7da819)
+++ uncommitted/git (mode:100755)
@@ -67,6 +67,7 @@
exit 1
fi
+[ -e "$HOME/.gitrc/$cmd" ] && set -- $(cat "$HOME/.gitrc/$cmd") "$@"
case "$cmd" in
"add") gitadd.sh "$@";;
cu
Fabian
PS: Should the commandline parsing be cleaned up or do you want to do that
after first release of cogito? And if yes, do you want to use "getopts" or
would this be not supported on some systems?
PPS: I'm fairly new to git, how do I create a diff with the signed-by fields
and with what do I need to sign it?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCaSZDI0lSH7CXz7MRAoq8AJwM2lxPfl0ej32WU7q6bh6WIq5+EACgghGn
mvJzbvg6/bxWLFKfsP1ZEeI=
=03wm
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Linus Torvalds @ 2005-04-22 16:22 UTC (permalink / raw)
To: Chris Mason; +Cc: Krzysztof Halasa, git
In-Reply-To: <200504212016.16729.mason@suse.com>
On Thu, 21 Apr 2005, Chris Mason wrote:
>
> We can sort by the files before reading them in, but even if we order things
> perfectly, we're spreading the io out too much across the drive.
No we don't.
It's easy to just copy the repository in a way where this just isn't true:
you sort the objects by how far they are from the current HEAD, and you
just copy the repository in that order ("furthest" objects first - commits
last).
That's what I meant by defragmentation - you can actually do this on your
own, even if your filesystem doesn't support it.
Do it twice a year, and I pretty much guarantee that your performance will
stay pretty constant over time. The one exception is fsck, which doesn't
seek in "history order".
And this works exactly because:
- we don't do no steenking delta's, and don't have deep "chains" of data
to follow. The longest chain we ever have is just a few deep, and it's
trivial to just encourage the filesystem to have recent things together.
- we have an append-only mentality.
In fact, it works for exactly the same reason that makes us able to drop
old history if we want to. We essentially "drop" the history to another
part of the disk.
Linus
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Kyle Hayes @ 2005-04-22 16:16 UTC (permalink / raw)
To: azarah; +Cc: GIT Mailing Lists
In-Reply-To: <1114179795.29271.18.camel@nosferatu.lan>
On Fri, 2005-04-22 at 16:23 +0200, Martin Schlemmer wrote:
> Hi,
>
> This still applies - any reason for not doing this?
Seems like this will break on certain kinds of data. See below.
> if (!pw)
> die("You don't exist. Go away!");
> realgecos = pw->pw_gecos;
> + /* The name is seperated from the room no., tel no, etc via [,;] */
> + if (strchr(realgecos, ','))
> + *strchr(realgecos, ',') = 0;
> + else if (strchr(realgecos, ';'))
> + *strchr(realgecos, ';') = 0;
> len = strlen(pw->pw_name);
> memcpy(realemail, pw->pw_name, len);
> realemail[len] = '@';
Suppose that the GECOS field is:
Hayes, Kyle; Room 42; 424-424-4242; foo bar baz...
You'll search for the first comma, find it, truncate my name to "Hayes",
and continue.
I have seen this kind of GECOS in larger environments where the
individual users are not the ones that administrate their machines.
Using the LastName, FirstName style of name is not rare.
I think you want something like this (not tested):
char *comma,*semi;
comma = strchr(realgecos,',');
semi = strchr(realgecos,';');
if(comma)
if(semi)
/* lastname, firstname; room #; phone # format */
*semi = 0;
else
*comma = 0;
else if(semi)
*semi = 0;
(hopefully Evolution won't trash the indentation...)
Best,
Kyle
--
Kyle Hayes <kyle@marchex.com>
Marchex Inc.
^ permalink raw reply
* Re: [PATCH] git-pasky debian dir
From: Chris Wright @ 2005-04-22 16:16 UTC (permalink / raw)
To: Joshua T. Corbin; +Cc: git
In-Reply-To: <200504220918.06977.jcorbin@wunjo.org>
* Joshua T. Corbin (jcorbin@wunjo.org) wrote:
> After seeing the spec file, I had to do this:
>
> You can get the binary here:
> http://node1.wunjo.org/~jcorbin/git-pasky_0.6.3-1_i386.deb
>
> alternatively you can pull from here:
> rsync://node1.wunjo.org/git/git
>
> It's against b31d16fad0013b3f106b227232559e24daf36962. It installs
> to /usr/bin, but I hacked things about so that *.sh goes
> in /usr/share/git-pasky/scripts. Haven't had many people try it yet, but it
> works for me; this isn't exactly my first debian package, but if anyone sees
> any glaring issues with it, I'd love to hear about it.
>
> --- /dev/null
> +++ 2f556bba4a059b3aaefb0bbacac64d60a14e127a/debian/scriptdir.diff
> @@ -0,0 +1,82 @@
> +diff -u a/Makefile b/Makefile
> +--- a/Makefile 2005-04-22 00:59:22.000000000 -0400
> ++++ b/Makefile 2005-04-22 00:59:43.000000000 -0400
> +@@ -18,6 +18,7 @@
> + prefix=$(HOME)
> +
> + bindir=$(prefix)/bin
> ++scriptdir=$(prefix)/share/git-pasky/scripts
> +
> + CC=gcc
> + AR=ar
> +@@ -28,11 +29,11 @@
> + check-files ls-tree merge-base merge-cache unpack-file git-export \
> + diff-cache convert-cache
> +
> +-SCRIPT= parent-id tree-id git gitXnormid.sh gitadd.sh gitaddremote.sh \
> +- gitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \
> +- gitmerge.sh gitpull.sh gitrm.sh gittag.sh gittrack.sh gitexport.sh \
> +- gitapply.sh gitcancel.sh gitXlntree.sh commit-id gitlsremote.sh \
> +- gitfork.sh gitinit.sh gitseek.sh gitstatus.sh gitpatch.sh \
> ++BINSCRIPTS= parent-id tree-id git gitdiff-do commit-id
> ++SCRIPT= gitXnormid.sh gitadd.sh gitaddremote.sh gitcommit.sh gitdiff.sh \
> ++ gitlog.sh gitls.sh gitlsobj.sh gitmerge.sh gitpull.sh gitrm.sh gittag.sh \
> ++ gittrack.sh gitexport.sh gitapply.sh gitcancel.sh gitXlntree.sh \
> ++ gitlsremote.sh gitfork.sh gitinit.sh gitseek.sh gitstatus.sh gitpatch.sh \
> + gitmerge-file.sh
> +
> + COMMON= read-cache.o
> +@@ -80,7 +81,9 @@
> +
> + install: $(PROG) $(GEN_SCRIPT)
> + install -m755 -d $(DESTDIR)$(bindir)
> +- install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(DESTDIR)$(bindir)
> ++ install -m755 -d $(DESTDIR)$(scriptdir)
> ++ install $(PROG) $(BINSCRIPTS) $(DESTDIR)$(bindir)
> ++ install $(SCRIPT) $(GEN_SCRIPT) $(DESTDIR)$(scriptdir)
This whole bit should be formalized. Ideally, I'd like to do /usr/bin/git
frontend, with all scripts in /usr/libexec/git/. However, this requires
something more than hardcoding paths.
> + clean:
> + rm -f *.o mozilla-sha1/*.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE)
> +diff -u a/commit-id b/commit-id
> +--- a/commit-id 2005-04-22 00:59:22.000000000 -0400
> ++++ b/commit-id 2005-04-22 01:02:40.000000000 -0400
> +@@ -5,4 +5,4 @@
> + #
> + # Takes the appropriate ID, defaults to HEAD.
> +
> +-gitXnormid.sh -c $1
> ++/usr/share/git-pasky/scripts/gitXnormid.sh -c $1
like this...
> +Common subdirectories: a/contrib and b/contrib
> +Only in b: debian
> +diff -u a/git b/git
> +--- a/git 2005-04-22 00:59:22.000000000 -0400
> ++++ b/git 2005-04-22 01:01:43.000000000 -0400
> +@@ -17,6 +17,7 @@
> + exit 1
> + }
> +
> ++export PATH=/usr/share/git-pasky/scripts:$PATH
Or this...
> + help () {
> + cat <<__END__
> +Common subdirectories: a/mozilla-sha1 and b/mozilla-sha1
> +diff -u a/parent-id b/parent-id
> +--- a/parent-id 2005-04-22 00:59:22.000000000 -0400
> ++++ b/parent-id 2005-04-22 01:02:01.000000000 -0400
> +@@ -7,6 +7,6 @@
> +
> + PARENT="^parent [A-Za-z0-9]{40}$"
> +
> +-id=$(gitXnormid.sh -c $1) || exit 1
> ++id=$(/usr/share/git-pasky/scripts/gitXnormid.sh -c $1) || exit 1
ditto...
> + cat-file commit $id | egrep "$PARENT" | cut -d ' ' -f 2
> +diff -u a/tree-id b/tree-id
> +--- a/tree-id 2005-04-22 00:59:22.000000000 -0400
> ++++ b/tree-id 2005-04-22 01:00:40.000000000 -0400
> +@@ -5,4 +5,4 @@
> + #
> + # Takes ID of the appropriate commit, defaults to HEAD.
> +
> +-gitXnormid.sh $1
> ++/usr/share/git-pasky/scripts/gitXnormid.sh $1
You get the idea ;-) I certainly see how it makes sense for a first
run to get it going. But this will need fixing upstream.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
From: Linus Torvalds @ 2005-04-22 16:13 UTC (permalink / raw)
To: Tomas Mraz; +Cc: Tom Lord, gnu-arch-users, gnu-arch-dev, git
In-Reply-To: <1114069758.5886.9.camel@perun.redhat.usu>
On Thu, 21 Apr 2005, Tomas Mraz wrote:
>
> However you're right that the original structure proposed by Linus is
> too flat.
You're wrong.
The thing is, having 256 sybdirectories already eats one _megabyte_ of
diskspace on common filessystems. If you expand that to be either deeper
(ie subdirectories within subdirectories), or use more than 8 bits for the
first level, you'll be using much more.
A megabyte of diskspace is peanuts for a project like Linux, but I think
it matters for small projects. I want git to work reasonably even for
really trivial stuff.
For example, if you just expand the fan-out to use 12 bits instead of 8,
you're now using 16MB of diskspace just for the directory structure, even
for a trivially small project. I just think that sucks.
Secondly, any sane OS (and filesystem) will look up flat directories
_faster_ than deep directories. Peter Anvid did the testing: a _totally_
flat directory is actually the best-performing one.
I just don't want to go there, because while it's ok to have tens of
thousands of files in one subdirectory, I don't think it's ok to have
hundreds of thousands of files. The 8-bit initial fan-out is very much a
middle ground: we waste some space (and some time) doing it, but it does
make the really horrible case largely go away.
Trust me, the design of git didn't just come out of my *ss. Unlike pretty
much apparently any other SCM engineer in the history of mankind (judging
by the performance crap that is out there), I actually know what performs
well, and I can calculate how much space we waste, and I actually _did_ do
so, and chose a reasonably intelligent middle ground.
You can bicker about the details (should it be 9 bits? should we pack the
names more densely? should we use another algorithm for compression? why
does it bother to use ASCII headers?), but please realize that those are
_details_. And even then, they are details where I bet that I have
selected pretty reasonable initial values.
So my choices may not be optimal, but they are "reasonable across a wide
variety of different parameters". And that includes project size,
filesystem implementation, disk wastage etc etc.
The only "extreme" choice I actually made was to go with the highest
compression level of zlib. I think I made the right choice there too: it
wastes CPU-time, but it's still pretty cheap(*) and keeps getting cheaper.
And we have a much higher read-to-write ratio that most other systems
have.
(*) I'll also argue that one reason even "-9" is cheap is actually that
most of the files we compress are small. All the metadata files are really
quite small, and most source-files tend to be just a few kB in size too -
I personally believe that _big_ files tend to be things that really change
quite seldom (things with big tables like firmware files etc). And for a
small file, it doesn't actually matter that much, the compression window
just can't grow too much.
So people say that "gzip -9" is expensive, but it's really expensive only
for large files. Try it out, it's just a personal pet theory of mine. But
realize that I _do_ generally think things through. I don't just cobble
together random things. There's a real _reason_ why git runs like a bat
out of hell. It was _designed_.
Linus
^ permalink raw reply
* Re: enforcing DB immutability
From: Bill Davidsen @ 2005-04-22 16:10 UTC (permalink / raw)
To: linux; +Cc: git, linux-kernel, mingo
In-Reply-To: <20050420084115.2699.qmail@science.horizon.com>
linux@horizon.com wrote:
> [A discussion on the git list about how to provide a hardlinked file
> that *cannot* me modified by an editor, but must be replaced by
> a new copy.]
>
> mingo@elte.hu wrote all of:
>
>>>>perhaps having a new 'immutable hardlink' feature in the Linux VFS
>>>>would help? I.e. a hardlink that can only be readonly followed, and
>>>>can be removed, but cannot be chmod-ed to a writeable hardlink. That i
>>>>think would be a large enough barrier for editors/build-tools not to
>>>>play the tricks they already do that makes 'readonly' files virtually
>>>>meaningless.
>>>
>>>immutable hardlinks have the following advantage: a hardlink by design
>>>hides the information where the link comes from. So even if an editor
>>>wanted to play stupid games and override the immutability - it doesnt
>>>know where the DB object is. (sure, it could find it if it wants to,
>>>but that needs real messing around - editors wont do _that_)
>>
>>so the only sensible thing the editor/tool can do when it wants to
>>change the file is precisely what we want: it will copy the hardlinked
>>files's contents to a new file, and will replace the old file with the
>>new file - a copy on write. No accidental corruption of the DB's
>>contents.
>
>
> This is not a horrible idea, but it touches on another sore point I've
> worried about for a while.
>
> The obvious way to do the above *without* changing anything is just to
> remove all write permission to the file. But because I'm the owner, some
> piece of software running with my permissions can just deicde to change
> the permissions back and modify the file anyway. Good old 7th edition
> let you give files away, which could have addressed that (chmod a-w; chown
> phantom_user), but BSD took that ability away to make accounting work.
>
> The upshot is that, while separate users keeps malware from harming the
> *system*, if I run a piece of malware, it can blow away every file I
> own and make me unhappy. When (notice I'm not saying "if") commercial
> spyware for Linux becomes common, it can also read every file I own.
>
> Unless I have root access, Linux is no safer *for me* than Redmondware!
>
> Since I *do* have root access, I often set up sandbox users and try
> commercial binaries in that environment, but it's a pain and laziness
> often wins. I want a feature that I can wrap in a script, so that I
> can run a commercial binary in a nicely restricted enviromment.
>
> Or maybe I even want to set up a "personal root" level, and run
> my normal interactive shells in a slightly restricted enviroment
> (within which I could make a more-restricted world to run untrusted
> binaries). Then I could solve the immutable DB issue by having a
> "setuid" binary that would make checked-in files unwriteable at my
> normal permission level.
>
> Obviously, a fundamental change to the Unix permissions model won't
> be available to solve short-term problems, but I thought I'd raise
> the issue to get people thinking about longer-term solutions.
chattr +i file
But the real problem is that you expect your editor to be smart enough
to diddle permissions (some aren't) or create a new file (some aren't
that either).
It sounds as if you're kind of using the wrong tool here, frankly.
You also don't understand hard links, they don't hide anything, the
inode number is there, which is exactly as much information as is in the
original link. And they are lots safer, since you can't wind up with
them pointing to a non-existent file, get them in circular loops, etc.
Okay, YOU probably wouldn't, but believe me semi-competent users
regularly these things.
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
^ permalink raw reply
* (anal) Q: Are there any coding styles or development guidelines?
From: Klaus Robert Suetterlin @ 2005-04-22 15:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504220838340.2344@ppc970.osdl.org>
I'm currently doing a source audit of the git core components.
Mainly I want to check if I can spot some left over memory leaks.
Unfortunately ;) I didn't find any so far (after reading five files).
Still I did find quite a lot of stuff that lint would most likely
complain about. Like not checking return values. Should this be
fixed now or isn't it time to do the cleanup, yet?
I also found several literal copies of the same function including
function name, parameter list, etc. Wouldn't it be better do clean
those up and put them in a utility.{c,h} file? A similar problem
is the continous reimplementation of linked lists, dynamic memory,
smart strings / vectors, etc. And then there are some stale files
(i.e. revision.*) that the Changelog already mentions as removed,
but which are still active in HEAD.
I am a little reluctant to do the work, as the code still changes
so fast I do not really know if code I fix will still be there
tomorrow.
Also I do not know if there is any notion of coding style published
somewhere. I only noticed, that the code does not look like anything
I'd have written and seems to follow some general principle.
Kind regards,
--Robert Suetterlin (robert@mpe.mpg.de)
phone: (+49)89 / 30000-3546 fax: (+49)89 / 30000-3950
^ permalink raw reply
* Re: Mozilla SHA1 implementation
From: Linus Torvalds @ 2005-04-22 15:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Edgar Toernig, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504220824480.2344@ppc970.osdl.org>
On Fri, 22 Apr 2005, Linus Torvalds wrote:
>
> > I get the opposite result on my 2GHz G5: the Mozilla version does
> > 45MB/s, the openssl version does 135MB/s, and my version does 218MB/s.
> > The time for a fsck-cache on a linux-2.6 tree (cache hot) is 8.0
> > seconds for the Mozilla version, 5.2 seconds for the openssl version,
> > and 4.4 seconds for my version.
>
> I get 16 seconds for the openssl one, and 8 for the Mozilla one. I'll try
> your version.
Ok, I get 4.9s on my kernel archive, so this is definitely a big win.
Can you sign off on the thing, since this is real new code? Let's do it
right.
Linus
^ permalink raw reply
* Re: Mozilla SHA1 implementation
From: Linus Torvalds @ 2005-04-22 15:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Edgar Toernig, Git Mailing List
In-Reply-To: <17000.43340.760901.175004@cargo.ozlabs.ibm.com>
On Fri, 22 Apr 2005, Paul Mackerras wrote:
> Linus Torvalds writes:
>
> > Interestingly, the Mozilla SHA1 code is about twice as fast as the openssl
> > code on my G5, and judging by the disassembly, it's because it's much
> > simpler. I think the openssl people have unrolled all the loops totally,
> > which tends to be a disaster on any half-way modern CPU. But hey, it could
> > be something as simple as optimization flags too.
>
> Which gcc version are you using?
gcc-3.3.3.
But it's more likely the precompiled libssl. I'm not compiling the openssl
thing myself, but just using the standard 0.9.7a version that comes with
YDL. Which, btw, causes all of
/lib/libcrypto.so.4
/usr/lib/libgssapi_krb5.so.2
/usr/lib/libkrb5.so.3
/lib/libcom_err.so.2
/usr/lib/libk5crypto.so.3
/lib/libresolv.so.2
/lib/libdl.so.2
to also be included. Oh, well.
> I get the opposite result on my 2GHz G5: the Mozilla version does
> 45MB/s, the openssl version does 135MB/s, and my version does 218MB/s.
> The time for a fsck-cache on a linux-2.6 tree (cache hot) is 8.0
> seconds for the Mozilla version, 5.2 seconds for the openssl version,
> and 4.4 seconds for my version.
I get 16 seconds for the openssl one, and 8 for the Mozilla one. I'll try
your version.
Linus
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 15:24 UTC (permalink / raw)
To: git
In-Reply-To: <1114183357.29271.31.camel@nosferatu.lan>
On Friday 22 Apr 2005 16:22, Martin Schlemmer wrote:
> On Fri, 2005-04-22 at 15:54 +0100, Rhys Hardwick wrote:
> > On Friday 22 Apr 2005 15:43, Rhys Hardwick wrote:
> > > On Friday 22 Apr 2005 15:44, Martin Schlemmer wrote:
> > > > On Fri, 2005-04-22 at 15:30 +0100, Rhys Hardwick wrote:
> > > > > On Friday 22 Apr 2005 15:00, Martin Schlemmer wrote:
> > > > > > On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> > > > > > > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > > > > > > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > > > > > > > Hey there,
> > > > > > > > >
> > > > > > > > > I am trying to pull the latest repository of the linux-2.6
> > > > > > > > > git from Linus' rsync mirror.
> > > > > > > > >
> > > > > > > > > Here is the shell:
> > > > > > > > >
> > > > > > > > > ===========
> > > > > > > > >
> > > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/lin
> > > > > > > > >ux-2 .6 .git defaulting to local storage area
> > > > > > > > > gitpull.sh: unknown remote
> > > > > > > > > gitinit.sh: pull failed
> > > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.g
> > > > > > > > >it defaulting to local storage area
> > > > > > > > > gitpull.sh: unknown remote
> > > > > > > > > gitinit.sh: pull failed
> > > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$
> > > > > > > > >
> > > > > > > > > =============
> > > > > > > > >
> > > > > > > > > Any idea why this is not working?
> > > > > > > >
> > > > > > > > Try:
> > > > > > > >
> > > > > > > > $ git init
> > > > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux
> > > > > > > >-2.6 .g it
> > > > > > >
> > > > > > > Exactly the same, sorry.....
> > > > > >
> > > > > > With latest git-pasky, after blowing the .git directory? I am
> > > > > > not sure (and have not checked) that git will do the right thing
> > > > > > if you retry without clearing.
> > > > >
> > > > > Yes to all the above. I pulled the latest today, and make && make
> > > > > install. Also, I have tried it with a .git in place, deleted, in
> > > > > the unpacked 2.6.11-r3 source, all of the above!
> > > > >
> > > > > >From what I can gather, it must happen in an empty directory, and
> > > > > > that is what
> > > > >
> > > > > the top two examples are.
> > > >
> > > > Really weird. I tested it my side before doing my last reply. Maybe
> > > > Petr will know.
> > >
> > > Hopefully!
> > >
> > > Thanks for the help anywho.....
> >
> > I think I have some more information. If you remove the -e from the
> > origins file, and put the name at the start of the line, it suddenly
> > works!!!
> >
> > Cool,
> >
> > Not sure what was going on there, but hey, Petr will work it out!
>
> Seems your /bin/sh do not support 'echo -e' ... Know what provides
> your /bin/sh (I think ash at least do support it)?
>
> Petr, I think you should really start to consider going full bash?
I use dash...
^ permalink raw reply
* Re: [PATCH] git-pasky spec file
From: Chris Wright @ 2005-04-22 15:21 UTC (permalink / raw)
To: Kevin Smith; +Cc: Chris Wright, git
In-Reply-To: <4269073C.1080802@qualitycode.com>
* Kevin Smith (yarcs@qualitycode.com) wrote:
> But presumably you'll change the name of this package to cogito soon
> anyway, as soon as git-pasky itself is renamed.
that's the plan.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Martin Schlemmer @ 2005-04-22 15:22 UTC (permalink / raw)
To: rhys; +Cc: git
In-Reply-To: <200504221554.04749.rhys@rhyshardwick.co.uk>
[-- Attachment #1: Type: text/plain, Size: 3043 bytes --]
On Fri, 2005-04-22 at 15:54 +0100, Rhys Hardwick wrote:
> On Friday 22 Apr 2005 15:43, Rhys Hardwick wrote:
> > On Friday 22 Apr 2005 15:44, Martin Schlemmer wrote:
> > > On Fri, 2005-04-22 at 15:30 +0100, Rhys Hardwick wrote:
> > > > On Friday 22 Apr 2005 15:00, Martin Schlemmer wrote:
> > > > > On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> > > > > > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > > > > > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > > > > > > Hey there,
> > > > > > > >
> > > > > > > > I am trying to pull the latest repository of the linux-2.6 git
> > > > > > > > from Linus' rsync mirror.
> > > > > > > >
> > > > > > > > Here is the shell:
> > > > > > > >
> > > > > > > > ===========
> > > > > > > >
> > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2
> > > > > > > >.6 .git defaulting to local storage area
> > > > > > > > gitpull.sh: unknown remote
> > > > > > > > gitinit.sh: pull failed
> > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > > > > > > defaulting to local storage area
> > > > > > > > gitpull.sh: unknown remote
> > > > > > > > gitinit.sh: pull failed
> > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$
> > > > > > > >
> > > > > > > > =============
> > > > > > > >
> > > > > > > > Any idea why this is not working?
> > > > > > >
> > > > > > > Try:
> > > > > > >
> > > > > > > $ git init
> > > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6
> > > > > > >.g it
> > > > > >
> > > > > > Exactly the same, sorry.....
> > > > >
> > > > > With latest git-pasky, after blowing the .git directory? I am not
> > > > > sure (and have not checked) that git will do the right thing if you
> > > > > retry without clearing.
> > > >
> > > > Yes to all the above. I pulled the latest today, and make && make
> > > > install. Also, I have tried it with a .git in place, deleted, in the
> > > > unpacked 2.6.11-r3 source, all of the above!
> > > >
> > > > >From what I can gather, it must happen in an empty directory, and that
> > > > > is what
> > > >
> > > > the top two examples are.
> > >
> > > Really weird. I tested it my side before doing my last reply. Maybe
> > > Petr will know.
> >
> > Hopefully!
> >
> > Thanks for the help anywho.....
> >
> > Rhys
>
> I think I have some more information. If you remove the -e from the origins
> file, and put the name at the start of the line, it suddenly works!!!
>
> Cool,
>
> Not sure what was going on there, but hey, Petr will work it out!
>
Seems your /bin/sh do not support 'echo -e' ... Know what provides
your /bin/sh (I think ash at least do support it)?
Petr, I think you should really start to consider going full bash?
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 14:54 UTC (permalink / raw)
To: git
In-Reply-To: <200504221543.43210.rhys@rhyshardwick.co.uk>
On Friday 22 Apr 2005 15:43, Rhys Hardwick wrote:
> On Friday 22 Apr 2005 15:44, Martin Schlemmer wrote:
> > On Fri, 2005-04-22 at 15:30 +0100, Rhys Hardwick wrote:
> > > On Friday 22 Apr 2005 15:00, Martin Schlemmer wrote:
> > > > On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> > > > > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > > > > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > > > > > Hey there,
> > > > > > >
> > > > > > > I am trying to pull the latest repository of the linux-2.6 git
> > > > > > > from Linus' rsync mirror.
> > > > > > >
> > > > > > > Here is the shell:
> > > > > > >
> > > > > > > ===========
> > > > > > >
> > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2
> > > > > > >.6 .git defaulting to local storage area
> > > > > > > gitpull.sh: unknown remote
> > > > > > > gitinit.sh: pull failed
> > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > > > > > defaulting to local storage area
> > > > > > > gitpull.sh: unknown remote
> > > > > > > gitinit.sh: pull failed
> > > > > > > rhys@metatron:~/repo/linux-2.6.repo$
> > > > > > >
> > > > > > > =============
> > > > > > >
> > > > > > > Any idea why this is not working?
> > > > > >
> > > > > > Try:
> > > > > >
> > > > > > $ git init
> > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6
> > > > > >.g it
> > > > >
> > > > > Exactly the same, sorry.....
> > > >
> > > > With latest git-pasky, after blowing the .git directory? I am not
> > > > sure (and have not checked) that git will do the right thing if you
> > > > retry without clearing.
> > >
> > > Yes to all the above. I pulled the latest today, and make && make
> > > install. Also, I have tried it with a .git in place, deleted, in the
> > > unpacked 2.6.11-r3 source, all of the above!
> > >
> > > >From what I can gather, it must happen in an empty directory, and that
> > > > is what
> > >
> > > the top two examples are.
> >
> > Really weird. I tested it my side before doing my last reply. Maybe
> > Petr will know.
>
> Hopefully!
>
> Thanks for the help anywho.....
>
> Rhys
I think I have some more information. If you remove the -e from the origins
file, and put the name at the start of the line, it suddenly works!!!
Cool,
Not sure what was going on there, but hey, Petr will work it out!
Rhys
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 14:43 UTC (permalink / raw)
To: git
In-Reply-To: <1114181091.29271.27.camel@nosferatu.lan>
On Friday 22 Apr 2005 15:44, Martin Schlemmer wrote:
> On Fri, 2005-04-22 at 15:30 +0100, Rhys Hardwick wrote:
> > On Friday 22 Apr 2005 15:00, Martin Schlemmer wrote:
> > > On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> > > > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > > > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > > > > Hey there,
> > > > > >
> > > > > > I am trying to pull the latest repository of the linux-2.6 git
> > > > > > from Linus' rsync mirror.
> > > > > >
> > > > > > Here is the shell:
> > > > > >
> > > > > > ===========
> > > > > >
> > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6
> > > > > >.git defaulting to local storage area
> > > > > > gitpull.sh: unknown remote
> > > > > > gitinit.sh: pull failed
> > > > > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > > > > defaulting to local storage area
> > > > > > gitpull.sh: unknown remote
> > > > > > gitinit.sh: pull failed
> > > > > > rhys@metatron:~/repo/linux-2.6.repo$
> > > > > >
> > > > > > =============
> > > > > >
> > > > > > Any idea why this is not working?
> > > > >
> > > > > Try:
> > > > >
> > > > > $ git init
> > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.g
> > > > >it
> > > >
> > > > Exactly the same, sorry.....
> > >
> > > With latest git-pasky, after blowing the .git directory? I am not sure
> > > (and have not checked) that git will do the right thing if you retry
> > > without clearing.
> >
> > Yes to all the above. I pulled the latest today, and make && make
> > install. Also, I have tried it with a .git in place, deleted, in the
> > unpacked 2.6.11-r3 source, all of the above!
> >
> > >From what I can gather, it must happen in an empty directory, and that
> > > is what
> >
> > the top two examples are.
>
> Really weird. I tested it my side before doing my last reply. Maybe
> Petr will know.
Hopefully!
Thanks for the help anywho.....
Rhys
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Martin Schlemmer @ 2005-04-22 14:44 UTC (permalink / raw)
To: rhys; +Cc: GIT Mailing Lists
In-Reply-To: <200504221530.32645.rhys@rhyshardwick.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]
On Fri, 2005-04-22 at 15:30 +0100, Rhys Hardwick wrote:
> On Friday 22 Apr 2005 15:00, Martin Schlemmer wrote:
> > On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> > > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > > > Hey there,
> > > > >
> > > > > I am trying to pull the latest repository of the linux-2.6 git from
> > > > > Linus' rsync mirror.
> > > > >
> > > > > Here is the shell:
> > > > >
> > > > > ===========
> > > > >
> > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > > > defaulting to local storage area
> > > > > gitpull.sh: unknown remote
> > > > > gitinit.sh: pull failed
> > > > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > > > defaulting to local storage area
> > > > > gitpull.sh: unknown remote
> > > > > gitinit.sh: pull failed
> > > > > rhys@metatron:~/repo/linux-2.6.repo$
> > > > >
> > > > > =============
> > > > >
> > > > > Any idea why this is not working?
> > > >
> > > > Try:
> > > >
> > > > $ git init
> > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > >
> > > Exactly the same, sorry.....
> >
> > With latest git-pasky, after blowing the .git directory? I am not sure
> > (and have not checked) that git will do the right thing if you retry
> > without clearing.
>
> Yes to all the above. I pulled the latest today, and make && make install.
> Also, I have tried it with a .git in place, deleted, in the unpacked
> 2.6.11-r3 source, all of the above!
>
> >From what I can gather, it must happen in an empty directory, and that is what
> the top two examples are.
>
Really weird. I tested it my side before doing my last reply. Maybe
Petr will know.
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [git pasky] tarball question
From: Martin Schlemmer @ 2005-04-22 14:31 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Petr Baudis
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
Hi,
I understand why you have the git-pasky-0.6.x.tar.bz2 tarballs with
the .git database included as well (btw, great stuff renaming it to
something more distributable), but its going to be a pita for users of
source based distro's like us (Gentoo), as well as our mirrors if it
gets much bigger. (Already asked r3pek to add it to portage).
How about ripping the .git directory from the next release, and just
have a un-numbered tarball (like you used to) that have the latest
snapshot of the .git directory for those that want to do git-pasky
development? Should even make things easier your side, as you could
just do a cron to update it one a day/whatever.
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: First web interface and service API draft
From: Jan Harkes @ 2005-04-22 14:23 UTC (permalink / raw)
To: Christian Meder; +Cc: git
In-Reply-To: <1114166517.3233.4.camel@localhost>
On Fri, Apr 22, 2005 at 12:41:56PM +0200, Christian Meder wrote:
> -------
> /<project>/blob/<blob-sha1>
> /<project>/commit/<commit-sha1>
It is trivial to find an object when given a sha, but to know the object
type you'd have to decompress it and check inside. Also the way git
stores these things you can't have both a blob and a commit with the
same sha anyways.
So why not use,
/<project/<hexadecimal sha1 representation>
will give you the raw object.
/<project/<hexadecimal sha1 representation>.html (.xml/.txt)
will give you a parsed version for user presentation
And since hexadecimal numbers only have [0-9a-f] as valid characters,
you can still have additional directories that can be guaranteed unique
as long as the first two characters are not a valid hexadecimal value.
So things like /branch/linus, or /changelog/, /log/, /diff/. Yeah, you
can't use /delta/ without looking at more than the first two characters,
but that's where dictionaries can come in handy.
Jan
^ permalink raw reply
* [patch] fixup GECOS handling
From: Martin Schlemmer @ 2005-04-22 14:23 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Linus Torvalds
In-Reply-To: <1113827713.5286.13.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 1514 bytes --]
Hi,
This still applies - any reason for not doing this?
Thanks,
----
The GECOS is delimited by ',' or ';', so we should only use whatever is
before the first ',' or ';' for the full name, rather than just
stripping those.
Signed-off-by: Martin Schlemmer <azarah@gentoo.org>
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.000000000 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via [,;] */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
[-- Attachment #1.2: git-gecos.patch --]
[-- Type: text/x-patch, Size: 917 bytes --]
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.000000000 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via ',' or ';' */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-pasky spec file
From: Kevin Smith @ 2005-04-22 14:16 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050422015521.GK493@shell0.pdx.osdl.net>
Chris Wright wrote:
> Here's a simple spec file to do rpm builds.
(snip)
> Creates a package named git, which seems
> fine since Linus' isn't likely to be packaged directly.
Um. Really? I can't imagine why Linus's git wouldn't be packaged
directly. He has strongly indicated that folks who want to build on top
of it should not expect to see libgit any time soon, so git will be an
important independent tool.
But presumably you'll change the name of this package to cogito soon
anyway, as soon as git-pasky itself is renamed.
Kevin
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Martin Schlemmer @ 2005-04-22 14:00 UTC (permalink / raw)
To: rhys; +Cc: git
In-Reply-To: <200504221450.48196.rhys@rhyshardwick.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]
On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > Hey there,
> > >
> > > I am trying to pull the latest repository of the linux-2.6 git from
> > > Linus' rsync mirror.
> > >
> > > Here is the shell:
> > >
> > > ===========
> > >
> > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > defaulting to local storage area
> > > gitpull.sh: unknown remote
> > > gitinit.sh: pull failed
> > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > defaulting to local storage area
> > > gitpull.sh: unknown remote
> > > gitinit.sh: pull failed
> > > rhys@metatron:~/repo/linux-2.6.repo$
> > >
> > > =============
> > >
> > > Any idea why this is not working?
> >
> > Try:
> >
> > $ git init
> > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
>
> Exactly the same, sorry.....
>
With latest git-pasky, after blowing the .git directory? I am not sure
(and have not checked) that git will do the right thing if you retry
without clearing.
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 13:50 UTC (permalink / raw)
To: git
In-Reply-To: <1114177940.29271.9.camel@nosferatu.lan>
On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > Hey there,
> >
> > I am trying to pull the latest repository of the linux-2.6 git from
> > Linus' rsync mirror.
> >
> > Here is the shell:
> >
> > ===========
> >
> > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > defaulting to local storage area
> > gitpull.sh: unknown remote
> > gitinit.sh: pull failed
> > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > defaulting to local storage area
> > gitpull.sh: unknown remote
> > gitinit.sh: pull failed
> > rhys@metatron:~/repo/linux-2.6.repo$
> >
> > =============
> >
> > Any idea why this is not working?
>
> Try:
>
> $ git init
> rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
Exactly the same, sorry.....
Rhys
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Martin Schlemmer @ 2005-04-22 13:52 UTC (permalink / raw)
To: rhys; +Cc: git
In-Reply-To: <200504221442.29488.rhys@rhyshardwick.co.uk>
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> Hey there,
>
> I am trying to pull the latest repository of the linux-2.6 git from Linus'
> rsync mirror.
>
> Here is the shell:
>
> ===========
>
> rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> defaulting to local storage area
> gitpull.sh: unknown remote
> gitinit.sh: pull failed
> rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> defaulting to local storage area
> gitpull.sh: unknown remote
> gitinit.sh: pull failed
> rhys@metatron:~/repo/linux-2.6.repo$
>
> =============
>
> Any idea why this is not working?
>
Try:
$ git init rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: First web interface and service API draft
From: Jon Seymour @ 2005-04-22 13:47 UTC (permalink / raw)
To: El Draper, git
In-Reply-To: <1114177468.3233.55.camel@localhost>
> >
> > >From the point of view of a specification, though, I think it would be
> > useful to focus on an XML content model rather than the details of one
> > particular HTML model - get the XML model right and you can do
> > whatever you like with the HTML model at any time after that.
>
> Actually I think the order is get the C content model right (done), get
> the Python object model right (in flux), produce an appropriate XML
> model.
Mmm.. I am not sure that a Python model is logically a pre-requisite
to the XML model nor that the ideal C API model is complete - we still
don't have a libgit, for example. For an XML model we can get by
pretty well with the data model as it is - and an XML model really
shouldn't be dependent on any particular API or programming language.
Certainly, though, an XML model isn't a pre-requisite to a Python
model. Though it might be a pre-req to a SOAP model :-).
jon.
^ permalink raw reply
* Re: First web interface and service API draft
From: Christian Meder @ 2005-04-22 13:44 UTC (permalink / raw)
To: El Draper; +Cc: git
In-Reply-To: <4268F027.6030304@eldiablo.co.uk>
On Fri, 2005-04-22 at 13:37 +0100, El Draper wrote:
> Christian Meder wrote:
>
> >Comments ? Ideas ? Other feedback ?
> >
> >
> >
>
> Hi guys,
>
> New around these parts, so be gentle :-)
>
> I would like to suggest the idea of a SOAP interface. If we are talking
> about a true service orientated API, then a way of calling a uri and
> having it return a nice SOAP packet with the return data in it would be
> great. If we ensured compliance with web service standards, then it
> would then mean anyone could write themselves a client desktop based
> program, a web interface, or any utility command line tools (in Java,
> .net, whatever they want, and for whatever platform), that could
> communicate with the web service and retrieve relevant data. You'd then
> have a true service interface into a Git repository. Seeing as how the
> idea of returning XML has already come up, I don't think it would be a
> stretch to extend the web interface to returning web service compliant
> SOAP packets in order to return data.
Ok, I should've known we get into this being a Web Java guy by
profession ;-)
Right now I'd like to concentrate more on a RESTful approach
http://www.xfront.com/REST-Web-Services.html
I'm concentrating on getting a clean and simple API for mere mortals and
developers alike. SOAP is likely further down on my list. But I
certainly will take patches ;-)
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
^ permalink raw reply
* Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 13:42 UTC (permalink / raw)
To: git
Hey there,
I am trying to pull the latest repository of the linux-2.6 git from Linus'
rsync mirror.
Here is the shell:
===========
rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
defaulting to local storage area
gitpull.sh: unknown remote
gitinit.sh: pull failed
rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
defaulting to local storage area
gitpull.sh: unknown remote
gitinit.sh: pull failed
rhys@metatron:~/repo/linux-2.6.repo$
=============
Any idea why this is not working?
Thanks for any help,
Rhys
^ 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