All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.