* [PATCH] Fix gcc-4 warning in accept() call
From: Pavel Roskin @ 2005-09-29 21:05 UTC (permalink / raw)
To: git
Fix gcc-4 warning in accept() call
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.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -459,7 +459,7 @@ static int serve(int port)
if (FD_ISSET(sockfd, &fds)) {
struct sockaddr_storage ss;
- int sslen = sizeof(ss);
+ unsigned int sslen = sizeof(ss);
int incoming = accept(sockfd, (struct sockaddr *)&ss, &sslen);
if (incoming < 0) {
switch (errno) {
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] fetch-pack should not ask for a ref which is already there
From: Linus Torvalds @ 2005-09-29 21:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0509292124190.8668@wgmdd8.biozentrum.uni-wuerzburg.de>
On Thu, 29 Sep 2005, Johannes Schindelin wrote:
>
> Wouldn't it make much more sense to add a flag which repairs an incomplete
> fetch?
No.
We've seen crap. We've _seen_ people use the old git-ssh-pull etc that
would result in incomplete repositories, and having people use the
"--recover" flag.
THAT KIND OF CRAP IS UNACCEPTABLE! I had to walk Andrew through a broken
repository because he had used those unreliable fetch methods. I was
ashamed of git at that point.
If a ^C results in a repository that needs to be fixed up, the "source
control management" is BROKEN. It's not source control, it's a buggy mess.
I refuse to use such tools. End of story. We do this right, or we don't do
it at all. And doing it right means that you only write refs after you've
downloaded everything, and you only _ever_ depend on refs. You don't
_ever_ say "if I have this object, I think I have everything".
The thing is, _reliability_ is #1. It's not performance. Performance is
important, but performance doesn't matter AT ALL if it comes at the
expense of reliability.
Linus
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Linus Torvalds @ 2005-09-29 21:14 UTC (permalink / raw)
To: Dave Jones
Cc: Anton Altaparmakov, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <20050929201127.GB31516@redhat.com>
On Thu, 29 Sep 2005, Dave Jones wrote:
>
> Ah. I didn't know this. Thanks.
> Hmm, it'd be nice to have a shorthand 'not have to type the url, pull everything'.
> Something like 'git pull all'.
Something like this?
Except it's called "git fetch --all", and it's obviously totally untested.
Linus
--
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -5,6 +5,8 @@
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+all=
+tags=
append=
force=
update_head_ok=
@@ -17,6 +19,12 @@ do
-f|--f|--fo|--for|--forc|--force)
force=t
;;
+ --tags)
+ tags=t
+ ;;
+ --all)
+ all=t
+ ;;
-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\
--update-he|--update-hea|--update-head|--update-head-|\
--update-head-o|--update-head-ok)
@@ -158,7 +166,16 @@ case "$update_head_ok" in
;;
esac
-for ref in $(get_remote_refs_for_fetch "$@")
+taglist=
+if [ "$tags$all" ]; then
+ pattern='/refs\/tags/'
+ if [ "$all" ]; then
+ pattern='/refs/'
+ fi
+ taglist=$(git-ls-remote "$remote" | awk "$pattern"' { print $2":"$2 }')
+fi
+
+for ref in $(get_remote_refs_for_fetch "$@" $taglist)
do
refs="$refs $ref"
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Chuck Lever @ 2005-09-29 21:23 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <433C4B6D.6030701@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
Jeff Garzik wrote:
> Dave Jones wrote:
>
>> You wrote..
>>
>> $ git clone
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> linux-2.6
>> $ cd linux-2.6
>> $ rsync -a --verbose --stats --progress \
>>
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>> \
>> .git/
>>
>> Could be just..
>>
>> $ git clone
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> linux-2.6
>> $ cd linux-2.6
>> $ git pull
>>
>> Likewise, in the next section, git pull doesn't need an argument
>> if pulling from the repo it cloned.
>
>
>
> Nope. It intentionally includes the manual rsync because clone/pull
> doesn't seem to grab tags. Or at least last time I checked...
i just used the instructions at the bottom of your web page to grab new
tags, and it completely wiped all my Stacked Git metadata. (fortunately
i was trying this in a test repository, and it will be simple to recover
the missing files).
so, this is probably something that should have a warning, or maybe you
might consider providing an example that won't wipe out existing files
and directories under .git/ ...
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH] Cogito README: add a block describing team workflow with git+ssh
From: Elfyn McBratney @ 2005-09-29 21:25 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
In-Reply-To: <11279754774179-git-send-email-martin@catalyst.net.nz>
[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]
On Thu, Sep 29, 2005 at 06:31:17 +1200, Martin Langhoff wrote:
> The README doesn't talk about teams with "peer" access to a shared repo.
> It took me a while to figure our the /right/ way to do it. Document for
> future generations and general happiness.
>
> Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
> [...]
>
> + $ chgroup gitcommit /var/git
s/chgroup/chgrp/
> + $ chmod 2775 /var/git
> + $ mkdir -p /var/git/projectname.git
> + $ GIT_DIR=/var/git/projectname.git git-init-db
Hmm .. if you're you're going to be using cogito anyway, might it be an
idea to instead do:
$ GIT_DIR=/var/git/projectname.git/.git cg-init [-I]
?
> +Note: All the developers with "commit" access must belong to the gitcommit
> +group and have a 002 umask on the remote server.
> +
> +Going back to your Cogito working copy, run
> +
> + $ git-push remoteserver:/var/git/projectname.git master branchname
Ditto here, tho' that'll require that remotes have been set-up, of
course. ;)
Anyhow, nice howto - thanks. :)
Best,
Elfyn
--
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc
PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Linus Torvalds @ 2005-09-29 21:26 UTC (permalink / raw)
To: Dave Jones
Cc: Anton Altaparmakov, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0509291413060.5362@g5.osdl.org>
On Thu, 29 Sep 2005, Linus Torvalds wrote:
>
> Something like this?
Gaah. Using a new pine version, and it is back to corrupting whitespace.
Damn all mailer writers. Do they think email is just for grandma?
Linus
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Elfyn McBratney @ 2005-09-29 21:33 UTC (permalink / raw)
To: Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0509291425560.5362@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 699 bytes --]
On Thu, Sep 29, 2005 at 02:26:42PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 29 Sep 2005, Linus Torvalds wrote:
> >Something like this?
>
> Gaah. Using a new pine version, and it is back to corrupting whitespace.
>
> Damn all mailer writers. Do they think email is just for grandma?
Of course - grandma uses pine, hackers use mutt ;)
*hides*
Best,
Elfyn
--
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc
PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Dave Jones @ 2005-09-29 21:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Anton Altaparmakov, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0509291425560.5362@g5.osdl.org>
On Thu, Sep 29, 2005 at 02:26:42PM -0700, Linus Torvalds wrote:
> On Thu, 29 Sep 2005, Linus Torvalds wrote:
> >
> >Something like this?
>
> Gaah. Using a new pine version, and it is back to corrupting whitespace.
>
> Damn all mailer writers. Do they think email is just for grandma?
What I find amusing is that it was a patch rejection mail from you
*years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
that made me switch MUA ;-)
All these years later, and it's still buggered ?
Dave
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Linus Torvalds @ 2005-09-29 21:35 UTC (permalink / raw)
To: Dave Jones
Cc: Anton Altaparmakov, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0509291425560.5362@g5.osdl.org>
On Thu, 29 Sep 2005, Linus Torvalds wrote:
>
> Gaah. Using a new pine version, and it is back to corrupting whitespace.
Ok, disabling "text flowing" seems to have fixed it. It still leaves empty
spaces at the end of lines when doing normal word-wrapping in the editor
(and then seems to use those empty spaces as a "marker" for flowing), but
that's at least just a small silly detail.
So how about this patch now? With it you can do
git fetch --tags <linus-kernel-repo>
and it should fetch all my tags automatically.
Linus
---
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -5,6 +5,8 @@
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+all=
+tags=
append=
force=
update_head_ok=
@@ -17,6 +19,12 @@ do
-f|--f|--fo|--for|--forc|--force)
force=t
;;
+ --tags)
+ tags=t
+ ;;
+ --all)
+ all=t
+ ;;
-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\
--update-he|--update-hea|--update-head|--update-head-|\
--update-head-o|--update-head-ok)
@@ -158,7 +166,16 @@ case "$update_head_ok" in
;;
esac
-for ref in $(get_remote_refs_for_fetch "$@")
+taglist=
+if [ "$tags$all" ]; then
+ pattern='/refs\/tags/'
+ if [ "$all" ]; then
+ pattern='/refs/'
+ fi
+ taglist=$(git-ls-remote "$remote" | awk "$pattern"' { print $2":"$2 }')
+fi
+
+for ref in $(get_remote_refs_for_fetch "$@" $taglist)
do
refs="$refs $ref"
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Dave Jones @ 2005-09-29 21:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Anton Altaparmakov, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0509291433040.5362@g5.osdl.org>
On Thu, Sep 29, 2005 at 02:35:15PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 29 Sep 2005, Linus Torvalds wrote:
> >
> > Gaah. Using a new pine version, and it is back to corrupting whitespace.
>
> Ok, disabling "text flowing" seems to have fixed it. It still leaves empty
> spaces at the end of lines when doing normal word-wrapping in the editor
> (and then seems to use those empty spaces as a "marker" for flowing), but
> that's at least just a small silly detail.
>
> So how about this patch now? With it you can do
>
> git fetch --tags <linus-kernel-repo>
>
> and it should fetch all my tags automatically.
Seems to work. I blew away git/refs/tags/v2.6.13*
and git fetch --tags fetched them all back just fine.
Dave
^ permalink raw reply
* Re: [PATCH] Cogito README: add a block describing team workflow with git+ssh
From: Martin Langhoff @ 2005-09-29 21:52 UTC (permalink / raw)
To: Elfyn McBratney, git, Martin Langhoff
In-Reply-To: <20050929212511.GA28106@zippy.emcb.local>
On 9/30/05, Elfyn McBratney <beu@gentoo.org> wrote:
> > + $ chgroup gitcommit /var/git
>
> s/chgroup/chgrp/
Ooops! Thanks for catching that
> > + $ chmod 2775 /var/git
> > + $ mkdir -p /var/git/projectname.git
> > + $ GIT_DIR=/var/git/projectname.git git-init-db
>
> Hmm .. if you're you're going to be using cogito anyway, might it be an
> idea to instead do:
>
> $ GIT_DIR=/var/git/projectname.git/.git cg-init [-I]
You only really need git on the repo server, and I think that's a plus.
> > + $ git-push remoteserver:/var/git/projectname.git master branchname
>
> Ditto here, tho' that'll require that remotes have been set-up, of
> course. ;)
Yes, the cogito way of doing this seems messy. Is there a simple way
to set up the remote branch and push to it?
cheers,
martin
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Linus Torvalds @ 2005-09-29 21:55 UTC (permalink / raw)
To: Dave Jones
Cc: Anton Altaparmakov, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <20050929213312.GD31516@redhat.com>
On Thu, 29 Sep 2005, Dave Jones wrote:
>
> What I find amusing is that it was a patch rejection mail from you
> *years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
> that made me switch MUA ;-)
>
> All these years later, and it's still buggered ?
Actually, it seems better. It seems to be buggered by default, but it used
to be that you had to actually recompile pine to make it behave. Now you
can just disable "strip-whitespace-before-send" and _enable_
"quell-flowed-text" and those together seem to do the trick. No extra
patches or recompiles necessary.
So there's progress.
Of course, pico is still pico. Which I find a bit sad: my editor of choise
is still an improved version of uemacs, and pico actually comes from the
same uemacs history, but has different key-bindings for just enough keys
to be slightly confusing.
Still, that shared history means that I find pico a lot more to my taste
than just about any other emailer editor out there. It may have a few
differences, but it has more things in common..
Linus
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Anton Altaparmakov @ 2005-09-29 22:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0509291451540.5362@g5.osdl.org>
On Thu, 29 Sep 2005, Linus Torvalds wrote:
> On Thu, 29 Sep 2005, Dave Jones wrote:
> > What I find amusing is that it was a patch rejection mail from you
> > *years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
> > that made me switch MUA ;-)
> >
> > All these years later, and it's still buggered ?
>
> Actually, it seems better. It seems to be buggered by default, but it used
> to be that you had to actually recompile pine to make it behave. Now you
> can just disable "strip-whitespace-before-send" and _enable_
> "quell-flowed-text" and those together seem to do the trick. No extra
> patches or recompiles necessary.
Indeed. I use those two options like that, too. (-:
> So there's progress.
>
> Of course, pico is still pico. Which I find a bit sad: my editor of choise
> is still an improved version of uemacs, and pico actually comes from the
> same uemacs history, but has different key-bindings for just enough keys
> to be slightly confusing.
>
> Still, that shared history means that I find pico a lot more to my taste
> than just about any other emailer editor out there. It may have a few
> differences, but it has more things in common..
Why don't you enable "enable-alternate-editor-implicitly" and set
editor = "your-editor-of-choice" in the pine config? It is integrated in
a quite seamless way.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
* Re: [PATCH] Cogito README: add a block describing team workflow with git+ssh
From: Elfyn McBratney @ 2005-09-29 22:19 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f905092914524d3cd8c1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
On Fri, Sep 30, 2005 at 09:52:11AM +1200, Martin Langhoff wrote:
> On 9/30/05, Elfyn McBratney <beu@gentoo.org> wrote:
> > > + $ chgroup gitcommit /var/git
> >
> > s/chgroup/chgrp/
>
> Ooops! Thanks for catching that
Np :)
> > > + $ chmod 2775 /var/git
> > > + $ mkdir -p /var/git/projectname.git
> > > + $ GIT_DIR=/var/git/projectname.git git-init-db
> >
> > Hmm .. if you're you're going to be using cogito anyway, might it be an
> > idea to instead do:
> >
> > $ GIT_DIR=/var/git/projectname.git/.git cg-init [-I]
>
> You only really need git on the repo server, and I think that's a plus.
*nods*
> > > + $ git-push remoteserver:/var/git/projectname.git master branchname
> >
> > Ditto here, tho' that'll require that remotes have been set-up, of
> > course. ;)
>
> Yes, the cogito way of doing this seems messy. Is there a simple way
> to set up the remote branch and push to it?
Not that I know of, tho' I'm still quite new to cogito, mind. ;)
Best,
Elfyn
--
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc
PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Linus Torvalds @ 2005-09-29 22:25 UTC (permalink / raw)
To: Anton Altaparmakov
Cc: Dave Jones, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.60.0509292309470.17860@hermes-1.csi.cam.ac.uk>
On Thu, 29 Sep 2005, Anton Altaparmakov wrote:
>
> Why don't you enable "enable-alternate-editor-implicitly" and set
> editor = "your-editor-of-choice" in the pine config? It is integrated in
> a quite seamless way.
You think so? I don't find it that way.
With an alternate editor you have to edit the headers separately, and
things like postponing a message suddenly turns into a big deal, not just
a trivial ^O. In fact, almost everything gets more involved.
And pico _is_ pretty close to uemacs.
Linus
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Anton Altaparmakov @ 2005-09-29 22:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0509291521300.5362@g5.osdl.org>
On Thu, 29 Sep 2005, Linus Torvalds wrote:
> On Thu, 29 Sep 2005, Anton Altaparmakov wrote:
> > Why don't you enable "enable-alternate-editor-implicitly" and set
> > editor = "your-editor-of-choice" in the pine config? It is integrated in
> > a quite seamless way.
>
> You think so? I don't find it that way.
>
> With an alternate editor you have to edit the headers separately, and
> things like postponing a message suddenly turns into a big deal, not just
> a trivial ^O. In fact, almost everything gets more involved.
Well using vim as alternate editor a postpone turns into a "ZZ" followed
by ^O which I don't think is such a big deal but in general I agree that
it adds hassle. It is a shame that the text based headers do not appear
as part of the message in the editor in particular...
> And pico _is_ pretty close to uemacs.
I wouldn't know about that. Never used uemacs. I am a vim addict myself.
(-;
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Junio C Hamano @ 2005-09-29 23:19 UTC (permalink / raw)
To: Anton Altaparmakov; +Cc: git
In-Reply-To: <Pine.LNX.4.60.0509292309470.17860@hermes-1.csi.cam.ac.uk>
Anton Altaparmakov <aia21@cam.ac.uk> writes:
> On Thu, 29 Sep 2005, Linus Torvalds wrote:
>> On Thu, 29 Sep 2005, Dave Jones wrote:
>> > What I find amusing is that it was a patch rejection mail from you
>> > *years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
>> > that made me switch MUA ;-)
>> >
>> > All these years later, and it's still buggered ?
>>
>> Actually, it seems better. It seems to be buggered by default, but it used
>> to be that you had to actually recompile pine to make it behave. Now you
>> can just disable "strip-whitespace-before-send" and _enable_
>> "quell-flowed-text" and those together seem to do the trick. No extra
>> patches or recompiles necessary.
>
> Indeed. I use those two options like that, too. (-:
Anybody interested in adding entry to SubmittingPatches MUA
Specific Help section?
^ permalink raw reply
* git push to a local directory with no .git in it
From: Richard Curnow @ 2005-09-29 23:25 UTC (permalink / raw)
To: git
Background: I have to use plain FTP to upload content to my web site. I keep a
local mirror of the entire site, then use an automated upload mechanism to do
the FTP step.
To release a git repository onto my site, I want to 'git push' from my working
area to the release area in the local mirror. So what ends up as
http://www.rpcurnow.force9.co.uk/git/mairix.git
lives in ~/homepage/git/mairix.git locally. That directory contains
HEAD, refs, objects, hooks; I don't have a .git subdirectory in the middle.
If I cd to ~/gitwork/mairix (which is a regular working area) and do
git push ~/homepage/git/mairix.git master:master
I get
fatal: /home/richard/homepage/git/mairix.git doesn't appear to be a git directory
presumably because there is no .git in it.
I could cd to ~/homepage/git/mairix.git and do things like
GIT_DIR=. gitk --all
but what's the equivalent of this GIT_DIR trick when it's the remote end of
a 'git push' that has the problem?
Cheers
Richard
^ permalink raw reply
* Re: [PATCH] Fix gcc-4 warning in accept() call
From: Horst von Brand @ 2005-09-29 23:11 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1128027901.24397.57.camel@dv>
Pavel Roskin <proski@gnu.org> wrote:
> Fix gcc-4 warning in accept() call
>
> 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.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> diff --git a/daemon.c b/daemon.c
> --- a/daemon.c
> +++ b/daemon.c
> @@ -459,7 +459,7 @@ static int serve(int port)
>
> if (FD_ISSET(sockfd, &fds)) {
> struct sockaddr_storage ss;
> - int sslen = sizeof(ss);
> + unsigned int sslen = sizeof(ss);
Shouldn't this be size_t?
> int incoming = accept(sockfd, (struct sockaddr *)&ss, &sslen);
> if (incoming < 0) {
> switch (errno) {
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Horst von Brand @ 2005-09-29 23:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Jones, Anton Altaparmakov, Jeff Garzik, Linux Kernel,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0509291451540.5362@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
[...]
> Of course, pico is still pico. Which I find a bit sad: my editor of choise
> is still an improved version of uemacs, and pico actually comes from the
> same uemacs history, but has different key-bindings for just enough keys
> to be slightly confusing.
Can I get a URL for the source for your editor? The one on kernel.org
doesn't compile, and probably hasn't for a long time.
[Yes, there is some (perverse) fun in telling people you use the very same
editor than Linus Torvalds :-]>
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* [PATCH] Fix handling of not_for_merge '.' flag in refspec.
From: Tom Prince @ 2005-09-29 23:53 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Tom Prince
canon_refs_list_for_fetch did not know about '.', so it mangled any
reference with it. Further, it added '.' to any refspec on the command
line other than the first.
Signed-off-by: Tom Prince <tom.prince@ualberta.net>
---
Documentation/pull-fetch-param.txt | 5 +++--
git-parse-remote.sh | 16 +++++++++++++++-
2 files changed, 18 insertions(+), 3 deletions(-)
446dda983492e3c07dc73b271cb9208a4359a734
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -49,7 +49,7 @@
<refspec>::
The canonical format of a <refspec> parameter is
- '+?<src>:<dst>'; that is, an optional plus '+', followed
+ '.?+?<src>:<dst>'; that is, an optional plus '+', followed
by the source ref, followed by a colon ':', followed by
the destination ref.
@@ -68,7 +68,8 @@
ref that matches it is fast forwarded using <src>.
Again, if the optional plus '+' is used, the local ref
is updated even if it does not result in a fast forward
- update.
+ update. If the optional dot '.' is used, the remote ref
+ is fetched, but not used for merging.
Some short-cut notations are also supported.
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -72,8 +72,15 @@ canon_refs_list_for_fetch () {
dot_prefix=
for ref
do
+ not_for_merge=
force=
case "$ref" in
+ .*)
+ ref=$(expr "$ref" : '\.\(.*\)')
+ not_for_merge=.
+ ;;
+ esac
+ case "$ref" in
+*)
ref=$(expr "$ref" : '\+\(.*\)')
force=+
@@ -94,7 +101,12 @@ canon_refs_list_for_fetch () {
heads/* | tags/* ) local="refs/$local" ;;
*) local="refs/heads/$local" ;;
esac
- echo "${dot_prefix}${force}${remote}:${local}"
+ case "$octopus$not_for_merge" in
+ '')
+ not_for_merge=$dot_prefix
+ ;;
+ esac
+ echo "${not_for_merge}${force}${remote}:${local}"
dot_prefix=.
done
}
@@ -114,6 +126,7 @@ get_remote_default_refs_for_fetch () {
# This prefixes the second and later default refspecs
# with a '.', to signal git-fetch to mark them
# not-for-merge.
+ octopus=
canon_refs_list_for_fetch $(sed -ne '/^Pull: */{
s///p
}' "$GIT_DIR/remotes/$1")
@@ -155,6 +168,7 @@ get_remote_refs_for_fetch () {
;;
esac
fi
+ octopus=t
canon_refs_list_for_fetch "$ref"
done
;;
^ permalink raw reply
* Re: git push to a local directory with no .git in it
From: Junio C Hamano @ 2005-09-30 0:05 UTC (permalink / raw)
To: Richard Curnow; +Cc: git
In-Reply-To: <loom.20050930T011606-58@post.gmane.org>
Richard Curnow <rc@rc0.org.uk> writes:
> I get
>
> fatal: /home/richard/homepage/git/mairix.git doesn't appear to be a git directory
>
> presumably because there is no .git in it.
Please don't presume, but dig.
$ git grep -n 'doesn.t appear to be'
receive-pack.c:275: die("%s doesn't appear to be a git directory", dir);
And the lines around there are:
/* chdir to the directory. If that fails, try appending ".git" */
if (chdir(dir) < 0) {
if (chdir(mkpath("%s.git", dir)) < 0)
die("unable to cd to %s", dir);
}
/* If we have a ".git" directory, chdir to it */
chdir(".git");
putenv("GIT_DIR=.");
if (access("objects", X_OK) < 0 || access("refs/heads", X_OK) < 0)
die("%s doesn't appear to be a git directory", dir);
write_head_info();
We chdir to mairix.git/, and then try to chdir to .git beneath
it _if_ _exists_; we do not care if the second chdir fails. So
if you do not have mairix.git/.git, that's OK. We will stay in
mairix.git/ directory and then set the GIT_DIR there.
If you do not have mairix.git/objects or mairix.git/refs/heads/
then that's when you get that error message.
$ cd /home/richard/homepage/git/mairix.git
$ ls -ld objects refs refs/heads
would tell us more.
^ permalink raw reply
* Re: [PATCH] Fix handling of not_for_merge '.' flag in refspec.
From: Junio C Hamano @ 2005-09-30 0:47 UTC (permalink / raw)
To: Tom Prince; +Cc: git
In-Reply-To: <11280379894186-git-send-email-tom.prince@ualberta.net>
Tom Prince <tom.prince@ualberta.net> writes:
> canon_refs_list_for_fetch did not know about '.', so it mangled any
> reference with it. Further, it added '.' to any refspec on the command
> line other than the first.
The dot trick was supposed to be internal. If you have the
following three lines in a remotes/xyzzy file:
URL: http://xyzzy.xz/balances.git
Pull: frotz nitfol
Pull: rezrov
$ git pull xyzzy
- fetch frotz, nitfol, and rezrov; merge frotz into the
current branch
$ git pull xyzzy nitfol
- fetch nitfol only; merge nitfol into the current branch.
$ git pull xyzzy nitfol rezrov
- fetch nitfol and rezrov; merge them into the current
branch (an Octopus).
The '.' is in no way part of the <refspec> format. It may not
be a bad idea to explicitly forbid it, but currently we don't.
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Linus Torvalds @ 2005-09-30 0:47 UTC (permalink / raw)
To: Horst von Brand
Cc: Dave Jones, Anton Altaparmakov, Jeff Garzik, Linux Kernel,
Git Mailing List
In-Reply-To: <200509292317.j8TNHC7S022247@inti.inf.utfsm.cl>
On Thu, 29 Sep 2005, Horst von Brand wrote:
>
> Can I get a URL for the source for your editor? The one on kernel.org
> doesn't compile, and probably hasn't for a long time.
Oh, it compiles with trivial modifications. Not cleanly, but it works.
I put my git repo on
kernel.org:/pub/software/editors/uemacs/uemacs.git
but it will take a moment to mirror out.
The "readme" says non-commercial only, but I asked Daniel Lawrence if it
was ok to include it in commercial distributions a long time ago, and he
said yes. Sadly, I've lost that email, so I don't have any paper trail for
that. So you should consider the readme binding.
> [Yes, there is some (perverse) fun in telling people you use the very same
> editor than Linus Torvalds :-]>
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. But I've got the keybindings hardcoded in my spine, so I can't
ever change.
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