From 3e63e0df4f1a1610782e679be56ea75f820343fc Mon Sep 17 00:00:00 2001 From: Gerrit Pape Date: Thu, 29 Mar 2007 06:41:42 +0000 Subject: [PATCH 1/3] Documentation/git-svnimport.txt: fix typo. This was noticed by Frederik Schwarzer. SVN's repository by default has trunk, tags/, and branch_es_/. Signed-off-by: Gerrit Pape Signed-off-by: Junio C Hamano --- Documentation/git-svnimport.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt index b166cf3327..bdae7d87dc 100644 --- a/Documentation/git-svnimport.txt +++ b/Documentation/git-svnimport.txt @@ -27,7 +27,7 @@ repository, or incrementally import into an existing one. SVN access is done by the SVN::Perl module. git-svnimport assumes that SVN repositories are organized into one -"trunk" directory where the main development happens, "branch/FOO" +"trunk" directory where the main development happens, "branches/FOO" directories for branches, and "/tags/FOO" directories for tags. Other subdirectories are ignored. From c2c6d9302a98ae4c4c76822a1c83551c039271a0 Mon Sep 17 00:00:00 2001 From: Gerrit Pape Date: Thu, 29 Mar 2007 06:42:44 +0000 Subject: [PATCH 2/3] Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES. Please see http://bugs.debian.org/404795: In git-rev-parse(1), there is an example commit tree, which is used twice. The explanation for this tree is very clear: B and C are commit *parents* to A. However, when the tree is reused as an example in the SPECIFYING RANGES, the manpage author screws up and uses A as a commit *parent* to B and C! I.e., he inverts the tree. And the fact that for this example you need to read the tree backwards is not explained anywhere (and it would be confusing even if it was). Signed-off-by: Gerrit Pape Signed-off-by: Junio C Hamano --- Documentation/git-rev-parse.txt | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 4041a16070..d0a2ad3088 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -258,14 +258,14 @@ its all parents. Here are a handful examples: - D A B D - D F A B C D F - ^A G B D - ^A F B C F - G...I C D F G I - ^B G I C D F G I - F^@ A B C - F^! H D F H + D G H D + D F G H I J D F + ^G D H D + ^D B E I J F B + B...C G H D E B C + ^D B C E I J F B C + C^@ I J F + F^! D G H D F Author ------ From 3ac53e0d13fa7483cce90eb6a1cfcdcbda5b8e35 Mon Sep 17 00:00:00 2001 From: "H. Peter Anvin" Date: Tue, 27 Mar 2007 16:45:06 -0700 Subject: [PATCH 3/3] git-upload-pack: make sure we close unused pipe ends Right now, we don't close the read end of the pipe when git-upload-pack runs git-pack-object, so we hang forever (why don't we get SIGALRM?) instead of dying with SIGPIPE if the latter dies, which seems to be the norm if the client disconnects. Thanks to Johannes Schindelin for pointing out where this close() needed to go. This patch has been tested on kernel.org for several weeks and appear to resolve the problem of git-upload-pack processes hanging around forever. Signed-off-by: H. Peter Anvin Signed-off-by: Junio C Hamano (cherry picked from commit 465b3518a9ad5080a4b652ef35fb13c61a93e7a4) --- upload-pack.c | 1 + 1 file changed, 1 insertion(+) diff --git a/upload-pack.c b/upload-pack.c index 3648aae1a7..044c33b090 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -119,6 +119,7 @@ static void create_pack_file(void) int i; struct rev_info revs; + close(lp_pipe[0]); pack_pipe = fdopen(lp_pipe[1], "w"); if (create_full_pack)