* Re: [howto] Kernel hacker's guide to git, updated
From: Erik Mouw @ 2005-09-30 12:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Junio C Hamano, git
In-Reply-To: <433D1E5D.20303@pobox.com>
On Fri, Sep 30, 2005 at 07:15:41AM -0400, Jeff Garzik wrote:
> >automatically. Running the following one-liner every once in a
> >while would sync your set of tags with Linus:
> >
> >git fetch origin `git-ls-remote --tags origin | sed -ne
> >'s|^.*refs/tags/|tag |p'`
>
> that's way too long and convoluted to deal with. Once the 'git fetch
> --tags' changes make it into the official repository (are they there
> already?), I'll remove all the remaining direct references to running rsync.
FYI, the rsync command to get the tags blows away .git/branches/origin,
so on the next "git pull", git will tell you "Where do you want to
fetch from today?".
In the mean time, better make it two separate rsync commands (sorry for
the long lines):
rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/tags/ \
.git/tags/
rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/heads/ \
.git/heads/
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Oliver Neukum @ 2005-09-30 12:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Junio C Hamano, git
In-Reply-To: <433D1E5D.20303@pobox.com>
Am Freitag, 30. September 2005 13:15 schrieb Jeff Garzik:
>
> Thanks for all the comments. I just updated the KHGtG with the feedback
> I received. Go to
>
> http://linux.yyz.us/git-howto.html
>
> and click reload. Continued criticism^H^H^Hcomments welcome!
>
The error is still there.
oliver@oenone:~/linux-2.6> git checkout -f master
usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
Regards
Oliver
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Junio C Hamano @ 2005-09-30 11:55 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, git
In-Reply-To: <433D1E5D.20303@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> ... Once the 'git fetch --tags' changes make it into the
> official repository (are they there already?), I'll remove all
> the remaining direct references to running rsync.
Sounds like a thinly veiled threat and/or very effective
prodding ;-).
It is not there yet only because I simply have not got around to
it, but it will happen before 0.99.8.
I suspect the version Linus posted has a funny interaction with
'git-pull'; 'git pull --tags' by mistake, or intentionally to
file a bug report to annoy me ;-), would create an Octopus out
of those tags, if I am not mistaken.
> 2) What is the easiest way to obtain a list of changes present in
> repository B, that are not present in repository A? I used to use
> git-changes-script [hacked cg-log script] for this:
I think I still have the copy you sent to the list. If you do
not mind me placing in the master branch just holler -- better
yet please send a patch with commit log and signoff to add the
latest, and I will apply it.
-jc
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Jeff Garzik @ 2005-09-30 11:15 UTC (permalink / raw)
To: Linux Kernel; +Cc: Junio C Hamano, git
In-Reply-To: <7virwjegb5.fsf@assigned-by-dhcp.cox.net>
Thanks for all the comments. I just updated the KHGtG with the feedback
I received. Go to
http://linux.yyz.us/git-howto.html
and click reload. Continued criticism^H^H^Hcomments welcome!
Two items of note:
1)
> automatically. Running the following one-liner every once in a
> while would sync your set of tags with Linus:
>
> git fetch origin `git-ls-remote --tags origin | sed -ne 's|^.*refs/tags/|tag |p'`
that's way too long and convoluted to deal with. Once the 'git fetch
--tags' changes make it into the official repository (are they there
already?), I'll remove all the remaining direct references to running rsync.
2) What is the easiest way to obtain a list of changes present in
repository B, that are not present in repository A? I used to use
git-changes-script [hacked cg-log script] for this:
$ cd /repo/netdev-2.6
$ git-changes-script -L ../linux-2.6
would display all changes in /repo/netdev-2.6 which are not present in
/repo/linux-2.6. This is similar to 'git log master..HEAD', except for
repositories rather than branches.
Jeff
^ permalink raw reply
* Re: [PATCH] Added an option to cvsimport to specify email domain
From: Alexey Nezhdanov @ 2005-09-30 10:22 UTC (permalink / raw)
To: Junio C Hamano, Matthias Urlichs, David Mansfield; +Cc: git
In-Reply-To: <7v64sj6iva.fsf@assigned-by-dhcp.cox.net>
On Friday 30, September 2005 12:48 Junio C Hamano wrote:
> Alexey Nezhdanov <snake@penza-gsm.ru> writes:
> > Unfortunately I do not know perl so I can not write a patch for
> > git-cvsimport-script. So I asking you, Matthias, to help with this or may
> > somebody on this list can do it instead.
>
> Untested, but something like this?
<skipped/>
Yes, now it works correctly and can go down to master IMHO. One little notice,
though. It is still prints out "* UNKNOWN LINE *" for each authorname in the
new format.
This is not result of your patch - it started doing this immidiatedly after I
tried updated version of cvsps (I have not mentioned this in my previous
mail, sorry). Let's wait if somebody will fix it.
In any way,
ANNOUNCE:
=========
With my patch to cvsps and Junio's patch to git-cvsimport.perl it is now
possible to import authorname+email pairs correctly basing on contents of
CVSROOT/users file. Currently cvsps can't retrieve this file in --cvs-direct
mode (that git-cvsimport.perl uses) so you'll need to check it out by hand.
May be if David will find some time for it this limitation will be lifted.
So now you can do either:
cvs checkout CVSROOT/users
or
mkdir CVSROOT && echo "author:A U Thor <author@domain.xz>" >CVSROOT/users
and then
git cvsimport -p "--users-file,CVSROOT/users"
you will import all mapped usernames correctly.
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Junio C Hamano @ 2005-09-30 10:02 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <433B3B10.5050407@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> I have set up a git-on-Cygwin temporary tree at:
>
> http://www.kernel.org/pub/scm/git/git-cygwin.git
: siamese; git clone http://kernel.org/pub/scm/git/git-cygwin.git/ git-cygwin
defaulting to local storage area
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
Could you do update-server-info there, please?
hera$ cd /pub/scm/git/git-cygwin.git
hera$ GIT_DIR=. git-update-server-info
Knowing nothing about Cygwin environment, here are some
comments.
+# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
This part probably is applicable outside Cygwin. At some point,
can we have it in the mainline please?
# The ones that do not have to link with lcrypto nor lz.
SIMPLE_PROGRAMS = \
- git-get-tar-commit-id git-mailinfo git-mailsplit git-stripspace \
- git-daemon git-var
+ git-get-tar-commit-id$(X) git-mailinfo$(X) git-mailsplit$(X) \
+ git-stripspace$(X) git-var$(X) git-daemon$(X)
I have seen these $(X) in other programs' ports and found them
quite distasteful. Since I do not have immediate suggestions
for improvements, I do not have rights to complain, though.
Spelling it $X is a bit less distracting but not that much
better. Maybe "SIMPLE_PROGRAM_NAMES = git-foo git-bar" and
"SIMPLE_PROGRAMS = $(patsubst %,%$X,$(SIMPLE_PROGRAM_NAMES))"...
but that would not help bits like this:
- PROGRAMS += git-http-fetch
+ PROGRAMS += git-http-fetch$(X)
or this:
-git-%: %.o $(LIB_FILE)
+git-%$(X): %.o $(LIB_FILE)
... so I'd shut up about this part.
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -1,9 +1,11 @@
#include "cache.h"
#include "pkt-line.h"
+#include <alloca.h>
Why? I do not see any use of alloca in the added code...
+#include <sys/poll.h>
Is poll preferrable over select in general? Some may have only
select available and others may have only poll available,
perhaps? In any case, this is probably relevant to wider
audience than just Cygwin; please give it to mainline at some
point, perhaps conditionally allowing either/both.
+ *socklist_p = malloc(sizeof(int));
+ pfd = calloc(socknum, sizeof(struct pollfd));
Please use xmalloc and xcalloc just for consistency.
test -x $path/git-$cmd && exec $path/git-$cmd "$@" ;;
+
+ # In case we're running on Cygwin...
+ test -x $path/git-$cmd.exe && exec $path/git-$cmd.exe "$@" ;;
esac
Hmph, I think you forgot to drop double semicolon there.
The git.sh script is munged by Makefile so presumably we could
fix this part up there, like:
git: git.sh Makefile
rm -f $@+ $@
sed -e '1s|#!.*/sh|#!$(SHELL_PATH)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@X@@/$X/g' <$@.sh >$@+
chmod +x $@+
mv $@+ $@
And then (a patch on top of your "master"):
diff --git a/git.sh b/git.sh
--- a/git.sh
+++ b/git.sh
@@ -12,10 +12,14 @@ case "$#" in
exit 0 ;;
esac
- test -x $path/git-$cmd && exec $path/git-$cmd "$@" ;;
+ test -x $path/git-$cmd && exec $path/git-$cmd "$@"
- # In case we're running on Cygwin...
- test -x $path/git-$cmd.exe && exec $path/git-$cmd.exe "$@" ;;
+ case '@@X@@' in
+ '')
+ ;;
+ *)
+ test -x $path/git-$cmd@@X@@ && exec $path/git-$cmd@@X@@ "$@" ;;
+ esac
esac
echo "Usage: git COMMAND [OPTIONS] [TARGET]"
^ permalink raw reply
* Re: [PATCH] Added an option to cvsimport to specify email domain
From: Junio C Hamano @ 2005-09-30 8:48 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: git
In-Reply-To: <200509301219.42087.snake@penza-gsm.ru>
Alexey Nezhdanov <snake@penza-gsm.ru> writes:
> Unfortunately I do not know perl so I can not write a patch for git-cvsimport-script.
> So I asking you, Matthias, to help with this or may somebody on this list can do it instead.
Untested, but something like this?
------------
[PATCH] Pass CVSps generated A U Thor <author@domain.xz> intact.
Alexey Nezhdanov updated CVSps to generate author-name and
author-email information in its output.
If the input looks like it has that already properly formatted,
use that without our own munging.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -510,7 +510,7 @@ unless($pid) {
my $state = 0;
-my($patchset,$date,$author,$branch,$ancestor,$tag,$logmsg);
+my($patchset,$date,$author_name,$author_email,$branch,$ancestor,$tag,$logmsg);
my(@old,@new);
my $commit = sub {
my $pid;
@@ -591,11 +591,11 @@ my $commit = sub {
}
exec("env",
- "GIT_AUTHOR_NAME=$author",
- "GIT_AUTHOR_EMAIL=$author",
+ "GIT_AUTHOR_NAME=$author_name",
+ "GIT_AUTHOR_EMAIL=$author_email",
"GIT_AUTHOR_DATE=".strftime("+0000 %Y-%m-%d %H:%M:%S",gmtime($date)),
- "GIT_COMMITTER_NAME=$author",
- "GIT_COMMITTER_EMAIL=$author",
+ "GIT_COMMITTER_NAME=$author_name",
+ "GIT_COMMITTER_EMAIL=$author_email",
"GIT_COMMITTER_DATE=".strftime("+0000 %Y-%m-%d %H:%M:%S",gmtime($date)),
"git-commit-tree", $tree,@par);
die "Cannot exec git-commit-tree: $!\n";
@@ -638,7 +638,7 @@ my $commit = sub {
print $out "object $cid\n".
"type commit\n".
"tag $xtag\n".
- "tagger $author <$author>\n"
+ "tagger $author_name <$author_email>\n"
or die "Cannot create tag object $xtag: $!\n";
close($out)
or die "Cannot create tag object $xtag: $!\n";
@@ -683,7 +683,11 @@ while(<CVS>) {
$state=3;
} elsif($state == 3 and s/^Author:\s+//) {
s/\s+$//;
- $author = $_;
+ if (/^(.*?)\s+<(.*)>/) {
+ ($author_name, $author_email) = ($1, $2);
+ } else {
+ $author_name = $author_email = $_;
+ }
$state = 4;
} elsif($state == 4 and s/^Branch:\s+//) {
s/\s+$//;
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Oliver Neukum @ 2005-09-30 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslvn6m6y.fsf@assigned-by-dhcp.cox.net>
Am Freitag, 30. September 2005 09:37 schrieb Junio C Hamano:
> Oliver Neukum <oliver@neukum.org> writes:
>
> > Am Donnerstag, 29. September 2005 21:34 schrieb Jon Loeliger:
> >> On Thu, 2005-09-29 at 14:08, Oliver Neukum wrote:
> >>
> >> > Unfortunately, following the instructions to the letter produces this:
> >> > oliver@oenone:~/linux-2.6> git checkout
> >> > usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
> >>
> >> Yeah. See if you still have a .git/HEADS that symlinks
> >> to a valid place or not...?
> >
> > oliver@oenone:~/linux-2.6> ls -la .git/
> > insgesamt 14
> > drwxrwxr-x 6 oliver users 224 2005-09-29 21:06 .
> > drwxr-xr-x 3 oliver users 72 2005-09-29 20:45 ..
> > -rw-rw-r-- 1 oliver users 19 2005-05-02 01:02 description
> > lrwxrwxrwx 1 oliver users 17 2005-09-29 21:06 HEAD -> refs/heads/master
> > -rw------- 1 oliver users 32 2005-09-29 21:06 index
>
> I wonder what that 32-byte small file called 'index' is doing
> there. If this is the kernel tree, its index file should weigh
> about 1.7MB if I recall correctly.
I have no idea, but the instructions as stated didn't work for me.
Can you replicate that?
Regards
Oliver
^ permalink raw reply
* Re: Edit log message after commit
From: Junio C Hamano @ 2005-09-30 8:24 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87br2bq2ot.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> writes:
> first, create new branch at where you wanna change the message
>
> git checkout -b temp HEAD^^^ # hmm... HEAD^3 doesn't work
Because it should be spelled HEAD~3. HEAD^3 is "the third
parent of HEAD" and usually does not exist, unless you are
talking about an Octopus merge of three or more branches.
^ permalink raw reply
* Re: [PATCH] Added an option to cvsimport to specify email domain
From: Alexey Nezhdanov @ 2005-09-30 8:19 UTC (permalink / raw)
To: David Mansfield, Matthias Urlichs; +Cc: git
In-Reply-To: <1127825656.30421.15.camel@gandalf.cobite.com>
On Tuesday 27, September 2005 16:54 David Mansfield wrote:
> On Tue, 2005-09-27 at 08:34 +0400, Alexey Nezhdanov wrote:
> > (Re-post. Sorry for any inconvenience.)
> >
> > On September 14, 2005 23:34 Petr Baudis wrote:
> > > Dear diary, on Wed, Sep 07, 2005 at 09:18:03PM CEST, I got a letter
> > > where Junio C Hamano <junkio@cox.net> told me that...
> > >
> > > > David K?.A?Negedal <davidk@lysator.liu.se> writes:
> > > > > The authorship info in commits created by git-cvsimport-script
> > > > > only contains the username of the CVS committer. This patch
> > > > > adds a flag -e <domain> to git-cvsimport-script that makes it
> > > > > possible to specify an email domain that is added to all email
> > > > > addresses in the commit "author" and "committer" fields.
> > > > >
> > > > > ---
> > > > > I have stopped using cvsimport, because cvsps seems to produce bad
> > > > > output on the repository I'm using it with, but I had already
> > > > > prepared this patch.
> > > >
> > > > Hmph. One reason the original implementation did not do this is
> > > > because Linus and other people wanted to have a repeatability,
> > > > so making this an optional thing is good, but if we go this
> > > > route, I think if it would be nicer to have a --author-map
> > > > option that lets you feed a list of:
> > > >
> > > > <author> ==> "A U Thor <author@author.dom>"
> > > >
> > > > mappings, instead of a single -e, which essentially does not add
> > > > much information to the result.
> > > >
> > > > I take that your oob comment indicates that you do not have much
> > > > incentive/inclination to further hack on this, so I am not
> > > > asking you to do the above even if you find my suggestion
> > > > worthwhile.
> > >
> > > Various tools use CVSROOT/users to map usernames to realname <email>.
> > > I actually wanted to send a patch, looked at the cvsimport script and
> > > got totally scared away (at least for now)... ;-)
> >
> > git uses cvsps output to determine authorship. Do you think if this
> > problem should be solved on cvsps side? It should be relatively easy
> > IMHO. David, can you add another key to output CVSROOT/users mapping
> > result instead of usernames if available?
>
> I apologize that I probably won't have time to look at this right now...
>
> David
Hello. I have improved my patch and tested it with git-cvsimport-script.
cvsps works as intended so I hope that you, David will accept this patch. You can find it here:
http://www.penza-gsm.ru/snake/use_CVSROOT_users.patch
Though git-cvsimport-script not works as good as I wanted. It confuses with cvsps output like
Author: Alexey Nezhdanov <snakeru at users.sourceforge.net>
and converts it to something like
Alexey Nezhdanov snakeru at users.sourceforge.net <Alexey Nezhdanov snakeru at users.sourceforge.net>
Unfortunately I do not know perl so I can not write a patch for git-cvsimport-script.
So I asking you, Matthias, to help with this or may somebody on this list can do it instead.
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: Edit log message after commit
From: Kevin Leung @ 2005-09-30 7:58 UTC (permalink / raw)
To: git
In-Reply-To: <tnxbr2ce0fo.fsf@arm.com>
Thanks Yashi and Catalin for the pointers. The information is exactly what
I was looking for. :-)
^ permalink raw reply
* Re: [PATCH] HTTP partial transfer support for object, pack, and index transfers
From: Junio C Hamano @ 2005-09-30 7:47 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20050928171404.GA15593@reactrix.com>
I took a look at this patch. It did not cleanly apply anymore,
but I merged it anyway, and then took the liberty of updating it
further, according to your response to my earlier comments.
They will appear near the tip of the proposed updates branch.
I'd appreciate it if you could check it out and see I did not
break things by mistake.
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Junio C Hamano @ 2005-09-30 7:37 UTC (permalink / raw)
To: Oliver Neukum; +Cc: git
In-Reply-To: <200509292138.26183.oliver@neukum.org>
Oliver Neukum <oliver@neukum.org> writes:
> Am Donnerstag, 29. September 2005 21:34 schrieb Jon Loeliger:
>> On Thu, 2005-09-29 at 14:08, Oliver Neukum wrote:
>>
>> > Unfortunately, following the instructions to the letter produces this:
>> > oliver@oenone:~/linux-2.6> git checkout
>> > usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
>>
>> Yeah. See if you still have a .git/HEADS that symlinks
>> to a valid place or not...?
>
> oliver@oenone:~/linux-2.6> ls -la .git/
> insgesamt 14
> drwxrwxr-x 6 oliver users 224 2005-09-29 21:06 .
> drwxr-xr-x 3 oliver users 72 2005-09-29 20:45 ..
> -rw-rw-r-- 1 oliver users 19 2005-05-02 01:02 description
> lrwxrwxrwx 1 oliver users 17 2005-09-29 21:06 HEAD -> refs/heads/master
> -rw------- 1 oliver users 32 2005-09-29 21:06 index
I wonder what that 32-byte small file called 'index' is doing
there. If this is the kernel tree, its index file should weigh
about 1.7MB if I recall correctly.
^ permalink raw reply
* [PATCH] archimport: Actually cope with merges from "remote" repositories. Plus: Nicer messages.
From: Martin Langhoff @ 2005-09-30 7:15 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
archimport was refusing to import commits that had merges from repositories
that it didn't know about. Fixed.
Also brings in nicer messages.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
git-archimport.perl | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
d118e96e7f08fcd0963eac8d9e6f18e13f553a41
diff --git a/git-archimport.perl b/git-archimport.perl
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -228,10 +228,12 @@ foreach my $ps (@psets) {
# skip commits already in repo
#
if (ptag($ps->{id})) {
- $opt_v && print "Skipping already imported: $ps->{id}\n";
+ $opt_v && print " * Skipping already imported: $ps->{id}\n";
next;
}
+ print " * Starting to work on $ps->{id}\n";
+
#
# create the branch if needed
#
@@ -675,6 +677,10 @@ sub find_parents {
# that branch.
#
foreach my $branch (keys %branches) {
+
+ # check that we actually know about the branch
+ next unless -e "$git_dir/refs/heads/$branch";
+
my $mergebase = `git-merge-base $branch $ps->{branch}`;
die "Cannot find merge base for $branch and $ps->{branch}" if $?;
chomp $mergebase;
^ permalink raw reply
* Re: [PATCH] Fix gcc-4 warning in accept() call
From: Junio C Hamano @ 2005-09-30 6:21 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Pavel Roskin, git
In-Reply-To: <433CD412.8020409@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Apparently I'm wrong; socklen_t is unsigned int at least on glibc for
> i386. I'll shut up now.
Ah, I should shut up too. Thanks for checking what we should
use.
^ permalink raw reply
* Re: [PATCH] Fix gcc-4 warning in accept() call
From: H. Peter Anvin @ 2005-09-30 5:58 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, Pavel Roskin, git
In-Reply-To: <433CD2E7.5090909@zytor.com>
H. Peter Anvin wrote:
> Junio C Hamano wrote:
>
>> Pavel Roskin <proski@gnu.org> writes:
>>
>>
>>> gcc-4 warns about sign mismatch in pointers. Third argument in accept()
>>> is socklen_t, which is unsigned. Since Linus doesn't like socklen_t
>>> (see commit 7fa090844f7d1624c7d1ffc621aae6aec84a1110), let's use
>>> unsigned int.
>>
>>
>> Based on the list comments, I'd drop this patch -- it appears
>> that gcc-4 warning is useless in this case.
>>
>
> No, it's not. The proper type, if you don't use socklen_t, is int, not
> unsigned int.
>
Apparently I'm wrong; socklen_t is unsigned int at least on glibc for
i386. I'll shut up now.
-hpa
^ permalink raw reply
* Re: [PATCH] Fix gcc-4 warning in accept() call
From: H. Peter Anvin @ 2005-09-30 5:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vachv9kbq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
>
>>gcc-4 warns about sign mismatch in pointers. Third argument in accept()
>>is socklen_t, which is unsigned. Since Linus doesn't like socklen_t
>>(see commit 7fa090844f7d1624c7d1ffc621aae6aec84a1110), let's use
>>unsigned int.
>
> Based on the list comments, I'd drop this patch -- it appears
> that gcc-4 warning is useless in this case.
>
No, it's not. The proper type, if you don't use socklen_t, is int, not
unsigned int.
-hpa
^ permalink raw reply
* Re: [PATCH] Old curl does not know about CURLOPT_SSLKEY
From: Junio C Hamano @ 2005-09-30 5:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0509291819090.7007@wgmdd8.biozentrum.uni-wuerzburg.de>
Thanks. Will apply.
Next time around, please CC me (or To me and CC list), if the
patch is trivial and for immediate application.
^ permalink raw reply
* Re: [PATCH] Make logerror() and loginfo() static
From: Junio C Hamano @ 2005-09-30 5:50 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1128027194.24397.50.camel@dv>
Thanks. Will apply.
Next time around, please CC me (or To me and CC list), if the
patch is trivial and for immediate application.
^ permalink raw reply
* Re: [PATCH] Fix gcc-4 warning in accept() call
From: Junio C Hamano @ 2005-09-30 5:49 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1128027901.24397.57.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> gcc-4 warns about sign mismatch in pointers. Third argument in accept()
> is socklen_t, which is unsigned. Since Linus doesn't like socklen_t
> (see commit 7fa090844f7d1624c7d1ffc621aae6aec84a1110), let's use
> unsigned int.
Based on the list comments, I'd drop this patch -- it appears
that gcc-4 warning is useless in this case.
^ permalink raw reply
* Re: [PATCH] Support SPARSE in Makefile, better SPARSE_FLAGS
From: Junio C Hamano @ 2005-09-30 5:46 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1128026765.24397.46.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> +# explicitly what architecture to check for.
> +SPARSE = sparse
> +SPARSE_FLAGS = -D__$(shell uname -i)__
: siamese; uname --version
uname (coreutils) 5.2.1
Written by David MacKenzie.
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
: siamese; uname -i
Try `uname --help' for more information.
Better alternatives?
^ permalink raw reply
* Re: [PATCH] Fix gcc-4 warning in accept() call
From: H. Peter Anvin @ 2005-09-30 4:46 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Horst von Brand, git
In-Reply-To: <20050930000917.rrwggw4g0gogs8w4@webmail.spamcop.net>
Pavel Roskin wrote:
> Quoting Horst von Brand <vonbrand@inf.utfsm.cl>:
>
>
>>>+ unsigned int sslen = sizeof(ss);
>>
>>Shouldn't this be size_t?
>
>
> No. That would actually break things on big-endian 64-bit platforms.
>
> You can see "info libc" for the whole story. My (limited!) understanding is
> that it should be 32-bit for compatibility reasons, so socklen_t was a trick to
> fool size_t proponents from the POSIX committee :-)
>
Formally it should be "socklen_t" or "int". It should *not* be
"unsigned int"!
-hpa
^ permalink raw reply
* Re: [PATCH] Fix gcc-4 warning in accept() call
From: Pavel Roskin @ 2005-09-30 4:09 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <200509292311.j8TNBZDm022135@inti.inf.utfsm.cl>
Quoting Horst von Brand <vonbrand@inf.utfsm.cl>:
> > + unsigned int sslen = sizeof(ss);
>
> Shouldn't this be size_t?
No. That would actually break things on big-endian 64-bit platforms.
You can see "info libc" for the whole story. My (limited!) understanding is
that it should be 32-bit for compatibility reasons, so socklen_t was a trick to
fool size_t proponents from the POSIX committee :-)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Linus Torvalds @ 2005-09-30 2:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtkzb9qo.fsf@assigned-by-dhcp.cox.net>
On Thu, 29 Sep 2005, Junio C Hamano wrote:
>
> Wouldn't underneath pub/scm/ be more appropriate and gitweb
> friendly?
Well, I don't actually have write permissions to anything there except for
udner the kernel tree. Also, I suspect there aren't all that many uemacs
users out there, and anybody who isn't already a uemacs user probably
shouldn't pick it up.
I don't think it has gotten any real development for the last ten years,
and while it was arguably the best editor twenty years ago (not a lot of
competition - what else worked on DOS, VMS and UNIX without being crazy
and modal?) it's definitely showing its age.
So since I already had a uemacs subdirectory, I just put the git archive
there too.
> Hmph. I vaguely recall in my distant past when I was still in
> school, I did my own Japanization of microEmacs. I wonder if
> yours share the same root -- I do not have the source of my
> version anymore so I have no way checking which ancient version
> I mucked with.
It's based on 3.9e, with some fixes by Petri Kutvonen at Helsinki
University. With various (slight) modernizations by yours truly (eg posix
termios support rather than the old "termio" stuff).
It _shouldn't_ be that hard to teach it about UTF-8, but every time I look
at it I realize that there is a lot of stuff that should be improved.
Converting it to K&R, getting rid of the things that made sense in the
80's but haven't made sense in ten years, re-indenting it (right now
it's a strange mix of indentation styles)..
And if you open a binary file with it, it will literally spew binary
characters to the tty, and can seriously confuse it due to the control
chars. Or if you have a really long line, it can SIGSEGV on you. Cute.
But dammit, I'm not giving it up.
Linus
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Junio C Hamano @ 2005-09-30 1:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0509291742170.3378@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I put my git repo on
>
> kernel.org:/pub/software/editors/uemacs/uemacs.git
>
> but it will take a moment to mirror out.
Wouldn't underneath pub/scm/ be more appropriate and gitweb
friendly?
> The thing is, it's not a wonderful editor. It's small, and good enough,
> but I really wished somebody wrote something that handled UTF-8, for
> example.
Hmph. I vaguely recall in my distant past when I was still in
school, I did my own Japanization of microEmacs. I wonder if
yours share the same root -- I do not have the source of my
version anymore so I have no way checking which ancient version
I mucked with.
^ 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