From: Andreas Ericsson <ae@op5.se>
To: git@vger.kernel.org
Subject: Re: User-relative paths
Date: Tue, 25 Oct 2005 09:47:21 +0200 [thread overview]
Message-ID: <435DE309.9090509@op5.se> (raw)
In-Reply-To: <20051023183757.GS30889@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Sun, Oct 23, 2005 at 11:41:52AM CEST, I got a letter
> where Andreas Ericsson <ae@op5.se> told me that...
>
>>Anyways, the attached patch does this. I've tested all the various
>>syntaxes and they work as expected. rsync, http and local files take the
>>same syntax as before. I haven't added support for user-relative paths
>>to the git-daemon (can't see the point, really) although that can be
>>done easily enough.
>
>
> It would be useful to add a [PATCH] tag to subject when you submit a
> patch, so that we notice it better. ;-)
>
Will do in the future. I thought it was auto-imported for buildtest if
it was.
> You don't update the documentation even though there seem to be some
> syntactic changes. You should at least update
>
> Documentation/pull-fetch-param.txt
>
True. I'll need to re-work the patch a bit to take Junio's RFC on paths
into account. I'll do this then.
> Also before Junio asks you, in the followup patches, you might want to
> sign off the patch if you want it integrated.
>
>
>>diff --git a/Makefile b/Makefile
>>index 903c57c..87188ea 100644
>>--- a/Makefile
>>+++ b/Makefile
>>@@ -359,6 +362,9 @@ git-cherry-pick: git-revert
>> %.o: %.S
>> $(CC) -o $*.o -c $(ALL_CFLAGS) $<
>>
>>+$(SERVERSIDE_PROGRAMS) : git-%$X : %.o srvside-ssh.o $(LIB_FILE)
>>+ $(CC) $(ALL_CFLAGS) -o $@ $(filter %o,$^) $(LIBS)
>>+
>> git-%$X: %.o $(LIB_FILE)
>> $(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
>>
>
>
> Why are you adding own compilation command, and why is it inconsistent
> with the git-%$X's one?
>
Mainly because I'm really no good at Makefiles and just noticed that
this seems to do what I want. My own projects rarely stretch over 15
files and it's usually just one or two binaries, so I haven't gotten
round to learning the finer points of make.
>
>>diff --git a/connect.c b/connect.c
>>index b171c5d..0d78b3e 100644
>>--- a/connect.c
>>+++ b/connect.c
>>@@ -436,33 +436,44 @@ static int git_tcp_connect(int fd[2], co
>>+ /* leading colon marks relative path for ssh.
>>+ * Check for host == url and default to PROTO_SSH to allow
>>+ * $ git fetch kernel.org:git
>>+ */
>>+ if(ptr && (!path || ptr < path)) {
>>+ if(host == url)
>>+ protocol = PROTO_SSH;
>>+
>>+ if(protocol == PROTO_SSH) {
>>+ *ptr = '\0';
>>+ path = ptr + 1;
>> }
>> }
>
>
> If I understand this right,
>
> ssh://foo.bar:baz/quux
>
> will make foo.bar the host and baz/quux the path. Please, do NOT do
> this! It is supposed to be a URL, dammit! And you know, URLs have
> defined _syntax_, and that's important at least every time the URL gets
> out of GIT's context. Or stop it calling URL altogether, to prevent any
> confusion. But in URLs, the space between : and / is a port definition.
> See also RFC3986 (aka STD066) and RFC2718.
>
> Thanks.
>
Right you are. I was thinking scp like syntax rather than url.
>
>>diff --git a/receive-pack.c b/receive-pack.c
>>index 8f157bc..9a040ff 100644
>>--- a/receive-pack.c
>>+++ b/receive-pack.c
>>@@ -265,18 +267,9 @@ int main(int argc, char **argv)
>> if (!dir)
>> usage(receive_pack_usage);
>>
>>- /* 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=.");
>>+ /* Find the right directory */
>>+ srvside_chdir(dir, 0);
>>
>>- 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();
>>
>> /* EOF */
>
>
> No srvside_chdir() declaration?
>
>
>>diff --git a/srvside-ssh.c b/srvside-ssh.c
>>new file mode 100644
>>index 0000000..0ed5d30
>>--- /dev/null
>>+++ b/srvside-ssh.c
>>@@ -0,0 +1,63 @@
>>+#include "cache.h"
>>+#include <unistd.h>
>>+#include <pwd.h>
>>+
>>+extern const char *__progname;
>
>
> How portable is this? It appears that no standard really defines this,
> and Google faintly hints at least some Cygwin-related problems...
>
Somewhat, but not very. It was more of a quick hack since the old code
had hardcoded program names. If this gets supported in git-daemon as
well it should say "git-daemon" in the error message, so I think either
pass it as a parameter or invent some git_progname variable and use some
small init-code for all programs.
>
>>diff --git a/upload-pack.c b/upload-pack.c
>>index accdba6..356c9b1 100644
>>--- a/upload-pack.c
>>+++ b/upload-pack.c
>>@@ -5,6 +5,7 @@
>> #include "object.h"
>>
>> static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
>>+extern void srvside_chdir(const char *path, int strict);
>>
>> #define MAX_HAS 256
>> #define MAX_NEEDS 256
>
>
> What about a .h file?
>
Prototype patch, sort of, and since it's only one function I thought
it'd be better to keep it as unobtrusive as possible.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2005-10-25 7:47 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-22 22:22 Server side programs Andreas Ericsson
2005-10-23 0:30 ` Junio C Hamano
2005-10-23 9:41 ` User-relative paths (was: Server side programs) Andreas Ericsson
2005-10-23 18:37 ` Petr Baudis
2005-10-23 19:50 ` User-relative paths Junio C Hamano
2005-10-23 22:25 ` Petr Baudis
2005-10-23 22:30 ` Junio C Hamano
2005-10-24 6:28 ` Daniel Barkalow
2005-10-25 7:47 ` Andreas Ericsson [this message]
2005-10-23 19:56 ` Junio C Hamano
2005-10-23 21:30 ` Linus Torvalds
2005-10-23 22:57 ` Junio C Hamano
2005-10-23 23:02 ` Junio C Hamano
2005-10-24 1:08 ` H. Peter Anvin
2005-10-24 1:37 ` Linus Torvalds
2005-10-24 1:44 ` H. Peter Anvin
2005-10-24 1:56 ` Junio C Hamano
2005-10-24 0:21 ` [PATCH] Add git-shell Junio C Hamano
2005-10-24 0:52 ` Linus Torvalds
2005-10-24 0:55 ` Linus Torvalds
2005-10-24 1:36 ` Junio C Hamano
2005-10-24 2:08 ` User-relative paths Junio C Hamano
2005-10-25 9:11 ` [PATCH] git_progname (was: Re: User-relative paths) Andreas Ericsson
2005-10-25 9:31 ` Petr Baudis
2005-10-25 11:12 ` [PATCH] git_progname Andreas Ericsson
2005-10-25 12:53 ` Andreas Ericsson
2005-10-25 13:32 ` Petr Baudis
2005-10-26 6:07 ` Junio C Hamano
2005-10-27 8:34 ` [PATCH] git_progname (was: Re: User-relative paths) Matthias Urlichs
2005-10-23 0:42 ` Server side programs Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=435DE309.9090509@op5.se \
--to=ae@op5.se \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).