git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 3/4] Server-side support for user-relative paths.
@ 2005-11-01 22:59 Andreas Ericsson
  2005-11-02  0:14 ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Andreas Ericsson @ 2005-11-01 22:59 UTC (permalink / raw)


Remove the redundant code from {receive,upload}-pack.c in favour of the
library code in path.c (previous patch) with documentation of the changes
to the affected programs.

Signed-off-by: Andreas Ericsson <ae@op5.se>

---

 Documentation/pull-fetch-param.txt |   35 +++++++++++++++++++++++++++--------
 receive-pack.c                     |   13 ++-----------
 upload-pack.c                      |   13 ++-----------
 3 files changed, 31 insertions(+), 30 deletions(-)

applies-to: 17cf0474b857a396561f2def13ac6ac6b01e1e33
dd1ddd3d653b28bd57092f0e243efa545cd214d3
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index e8db9d7..33ee02e 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -1,16 +1,35 @@
 <repository>::
-	The "remote" repository to pull from.  One of the
-	following notations can be used to name the repository
-	to pull from:
+	The repository to pull/fetch from or push to.  The following
+	notations can be used to name the repository:
 +
 ===============================================================
-- Rsync URL:		rsync://remote.machine/path/to/repo.git/
-- HTTP(s) URL:		http://remote.machine/path/to/repo.git/
-- git URL:		git://remote.machine/path/to/repo.git/
-			or remote.machine:/path/to/repo.git/
-- Local directory:	/path/to/repo.git/
+- rsync://host.xz/path/to/repo.git/
+- http://host.xz/path/to/repo.git/
+- https://host.xz/path/to/repo.git/
+- git://host.xz/path/to/repo.git/
+- git://host.xz/~user/path/to/repo.git/
+- ssh://host.xz/path/to/repo.git/
+- ssh://host.xz/~user/path/to/repo.git/
 ===============================================================
 +
+	SSH Is the default transport protocol and also supports an
+	scp-like syntax.  Both syntaxes support username expansion,
+	as does the git-protocol. The following two are	identical
+	to the last two above:
++
+===============================================================
+- host.xz:/path/to/repo.git/
+- host.xz:~user/path/to/repo.git/
+===============================================================
++
+	To sync with a local directory, use:
++
+===============================================================
+- /path/to/repo.git/
+===============================================================
++
+Note that you can't push via HTTP or HTTPS.
++
 In addition to the above, as a short-hand, the name of a
 file in $GIT_DIR/remotes directory can be given; the
 named file should be in the following format:
diff --git a/receive-pack.c b/receive-pack.c
index 8f157bc..2c56018 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -265,18 +265,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=.");
+	if(!is_git_repo(dir, 0))
+		die("'%s': unable to chdir or not a git archive", 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();
 
 	/* EOF */
diff --git a/upload-pack.c b/upload-pack.c
index c5eff21..86e2a61 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -275,18 +275,9 @@ int main(int argc, char **argv)
 		usage(upload_pack_usage);
 	dir = argv[i];
 
-	/* chdir to the directory. If that fails, try appending ".git" */
-	if (chdir(dir) < 0) {
-		if (strict || chdir(mkpath("%s.git", dir)) < 0)
-			die("git-upload-pack unable to chdir to %s", dir);
-	}
-	if (!strict)
-		chdir(".git");
+	if(!is_git_repo(dir, strict))
+		die("'%s': unable to chdir or not a git archive", dir);
 
-	if (access("objects", X_OK) || access("refs", X_OK))
-		die("git-upload-pack: %s doesn't seem to be a git archive", dir);
-
-	putenv("GIT_DIR=.");
 	upload_pack();
 	return 0;
 }
---
0.99.9.GIT

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH 3/4] Server-side support for user-relative paths.
  2005-11-01 22:59 [PATCH 3/4] Server-side support for user-relative paths Andreas Ericsson
@ 2005-11-02  0:14 ` Junio C Hamano
  2005-11-02  8:30   ` Andreas Ericsson
  0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2005-11-02  0:14 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: git

Andreas Ericsson <ae@op5.se> writes:

> Remove the redundant code from {receive,upload}-pack.c in favour of the
> library code in path.c (previous patch) with documentation of the changes
> to the affected programs.

I like the simplification of these two calling sites, but it
makes me feel uneasy to see the workhorse named is_git_repo().

The name implies a check to see if the given path is a git repo
or not (i.e. side-effect free predicate), while what it actually
does are three things: (1) resolve and check, (2) chdir to it,
(3) set up GIT_DIR environment.  Not that I have a better name
in mind...

> +	SSH Is the default transport protocol and also supports an

Just a typo ("Is")?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 3/4] Server-side support for user-relative paths.
  2005-11-02  0:14 ` Junio C Hamano
@ 2005-11-02  8:30   ` Andreas Ericsson
  2005-11-02  9:47     ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Andreas Ericsson @ 2005-11-02  8:30 UTC (permalink / raw)
  To: git

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> 
>>Remove the redundant code from {receive,upload}-pack.c in favour of the
>>library code in path.c (previous patch) with documentation of the changes
>>to the affected programs.
> 
> 
> I like the simplification of these two calling sites, but it
> makes me feel uneasy to see the workhorse named is_git_repo().
> 
> The name implies a check to see if the given path is a git repo
> or not (i.e. side-effect free predicate), while what it actually
> does are three things: (1) resolve and check, (2) chdir to it,
> (3) set up GIT_DIR environment.  Not that I have a better name
> in mind...
> 

I went with this implementation because when I tried to break it up I 
had to add the chdir() and putenv() calls in the three callers. No 
programs in the git-suite tries to resolve the canonical path of a repo 
without subsequently entering it and using it.

Perhaps it should be enter_repo() or some such? Optionally with 
is_git_repo() as a separate function?

> 
>>+	SSH Is the default transport protocol and also supports an
> 
> 
> Just a typo ("Is")?
> 

Yes.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 3/4] Server-side support for user-relative paths.
  2005-11-02  8:30   ` Andreas Ericsson
@ 2005-11-02  9:47     ` Junio C Hamano
  0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2005-11-02  9:47 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: git

Andreas Ericsson <ae@op5.se> writes:

> I went with this implementation because...
> Perhaps it should be enter_repo() or some such? Optionally with 
> is_git_repo() as a separate function?

I agree with you that splitting this into three separate
functions does not make much sense.  I was just unsure about
that name; enter_repo() sounds more sensible.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-11-02  9:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-01 22:59 [PATCH 3/4] Server-side support for user-relative paths Andreas Ericsson
2005-11-02  0:14 ` Junio C Hamano
2005-11-02  8:30   ` Andreas Ericsson
2005-11-02  9:47     ` Junio C Hamano

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).