From 7ee70a7119e7d7edc1f85992d0ba8860c1c60a96 Mon Sep 17 00:00:00 2001
From: Theodore Tso <tytso@mit.edu>
Date: Tue, 27 Feb 2007 10:43:28 -0500
Subject: [PATCH 1/7] Fix git-show man page formatting in the EXAMPLES section
Fix asciidoc markup so that the man page is properly formatted in the
EXAMPLES section.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-show.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index f56f16498..5a219ab57 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -48,15 +48,15 @@ git show v1.0.0::
Shows the tag `v1.0.0`, along with the object the tags
points at.
-git show v1.0.0^{tree}::
+git show v1.0.0^\{tree\}::
Shows the tree pointed to by the tag `v1.0.0`.
-git show next~10:Documentation/README
+git show next~10:Documentation/README::
Shows the contents of the file `Documentation/README` as
they were current in the 10th last commit of the branch
`next`.
-git show master:Makefile master:t/Makefile
+git show master:Makefile master:t/Makefile::
Concatenates the contents of said Makefiles in the head
of the branch `master`.
From aa27e46111a777ae8b11e00675e13b1a9cde7fc2 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 27 Feb 2007 16:22:52 -0800
Subject: [PATCH 2/7] git-show: Reject native ref
So when we do
git show v1.4.4..v1.5.0
that's an illogical thing to do, since "git show" is defined to be a
non-revision-walking action, which means the range operator be pointless
and wrong. The fact that we happily accept it (and then _only_ show
v1.5.0, which is the positive end of the range) is quite arguably not very
logical.
We should complain, and say that you can only do "no_walk" with positive
refs. Negative object refs really don't make any sense unless you walk
the obejct list (or you're "git diff" and know about ranges explicitly).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
revision.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/revision.c b/revision.c
index 15bdaf609..76499dcf3 100644
--- a/revision.c
+++ b/revision.c
@@ -116,6 +116,8 @@ void mark_parents_uninteresting(struct commit *commit)
void add_pending_object(struct rev_info *revs, struct object *obj, const char *name)
{
+ if (revs->no_walk && (obj->flags & UNINTERESTING))
+ die("object ranges do not make sense when not walking revisions");
add_object_array(obj, name, &revs->pending);
if (revs->reflog_info && obj->type == OBJ_COMMIT)
add_reflog_for_walk(revs->reflog_info,
From 0a43acbe85fedf0226bd04aa210c529c72325982 Mon Sep 17 00:00:00 2001
From: Michael Poole <mdpoole@troilus.org>
Date: Tue, 27 Feb 2007 22:27:44 -0500
Subject: [PATCH 3/7] Correct ordering in git-cvsimport's option documentation
A pair of commits on January 8th added option documentation (for -a,
-S and -L) in the middle of the documentation for the -A option. This
makes -A's documentation contiguous again.
Signed-off-by: Michael Poole <mdpoole@troilus.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-cvsimport.txt | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index f5450de74..0d59c0613 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -96,11 +96,6 @@ If you need to pass multiple options, separate them with a comma.
-s <subst>::
Substitute the character "/" in branch names with <subst>
--A <author-conv-file>::
- CVS by default uses the Unix username when writing its
- commit logs. Using this option and an author-conv-file
- in this format
-
-a::
Import all commits, including recent ones. cvsimport by default
skips commits that have a timestamp less than 10 minutes ago.
@@ -112,6 +107,10 @@ If you need to pass multiple options, separate them with a comma.
Limit the number of commits imported. Workaround for cases where
cvsimport leaks memory.
+-A <author-conv-file>::
+ CVS by default uses the Unix username when writing its
+ commit logs. Using this option and an author-conv-file
+ in this format
+
---------
exon=Andreas Ericsson <ae@op5.se>
From 79c96c573357385cdc6d15b37bf65e5c137092ef Mon Sep 17 00:00:00 2001
From: Michael Coleman <tutufan@gmail.com>
Date: Tue, 27 Feb 2007 22:13:09 -0600
Subject: [PATCH 4/7] Fix minor typos/grammar in user-manual.txt
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/user-manual.txt | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c5e9ea8a4..7b6dc22e7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2,7 +2,7 @@ Git User's Manual
_________________
This manual is designed to be readable by someone with basic unix
-commandline skills, but no previous knowledge of git.
+command-line skills, but no previous knowledge of git.
Chapter 1 gives a brief overview of git commands, without any
explanation; you may prefer to skip to chapter 2 on a first reading.
@@ -1196,7 +1196,7 @@ will be HEAD, the tip of the current branch; the other will be the
tip of the other branch, which is stored temporarily in MERGE_HEAD.
The diff above shows the differences between the working-tree version
-of file.txt and two previous version: one version from HEAD, and one
+of file.txt and two previous versions: one version from HEAD, and one
from MERGE_HEAD. So instead of preceding each line by a single "+"
or "-", it now uses two columns: the first column is used for
differences between the first parent and the working directory copy,
@@ -1479,7 +1479,7 @@ Examining dangling objects
In some situations the reflog may not be able to save you. For
example, suppose you delete a branch, then realize you need the history
-it pointed you. The reflog is also deleted; however, if you have not
+it contained. The reflog is also deleted; however, if you have not
yet pruned the repository, then you may still be able to find
the lost commits; run git-fsck and watch for output that mentions
"dangling commits":
@@ -1505,7 +1505,7 @@ history that is described by all your existing branches and tags. Thus
you get exactly the history reachable from that commit that is lost.
(And notice that it might not be just one commit: we only report the
"tip of the line" as being dangling, but there might be a whole deep
-and complex commit history that was gotten dropped.)
+and complex commit history that was dropped.)
If you decide you want the history back, you can always create a new
reference pointing to it, for example, a new branch:
@@ -1561,7 +1561,7 @@ repository that you pulled from.
(But note that no such commit will be created in the case of a
<<fast-forwards,fast forward>>; instead, your branch will just be
-updated to point to the latest commit from the upstream branch).
+updated to point to the latest commit from the upstream branch.)
The git-pull command can also be given "." as the "remote" repository,
in which case it just merges in a branch from the current repository; so
@@ -1638,8 +1638,8 @@ updates with git pull>>".
If you and maintainer both have accounts on the same machine, then
then you can just pull changes from each other's repositories
-directly; note that all of the command (gitlink:git-clone[1],
-git-fetch[1], git-pull[1], etc.) which accept a URL as an argument
+directly; note that all of the commands (gitlink:git-clone[1],
+git-fetch[1], git-pull[1], etc.) that accept a URL as an argument
will also accept a local file patch; so, for example, you can
use
@@ -1832,7 +1832,7 @@ that makes it easy for them to read your changes, verify that they are
correct, and understand why you made each change.
If you present all of your changes as a single patch (or commit), they
-may find it is too much to digest all at once.
+may find that it is too much to digest all at once.
If you present them with the entire history of your work, complete with
mistakes, corrections, and dead ends, they may be overwhelmed.
@@ -1858,11 +1858,8 @@ you are rewriting history.
Keeping a patch series up to date using git-rebase
--------------------------------------------------
-Suppose you have a series of commits in a branch "mywork", which
-originally branched off from "origin".
-
-Suppose you create a branch "mywork" on a remote-tracking branch
-"origin", and created some commits on top of it:
+Suppose that you create a branch "mywork" on a remote-tracking branch
+"origin", and create some commits on top of it:
-------------------------------------------------
$ git checkout -b mywork origin
@@ -1966,7 +1963,7 @@ Other tools
-----------
There are numerous other tools, such as stgit, which exist for the
-purpose of maintaining a patch series. These are out of the scope of
+purpose of maintaining a patch series. These are outside of the scope of
this manual.
Problems with rewriting history
@@ -2088,7 +2085,7 @@ descendant of the old head, you may force the update with:
$ git fetch git://example.com/proj.git +master:refs/remotes/example/master
-------------------------------------------------
-Note the addition of the "+" sign. Be aware that commits which the
+Note the addition of the "+" sign. Be aware that commits that the
old version of example/master pointed at may be lost, as we saw in
the previous section.
@@ -2096,7 +2093,7 @@ Configuring remote branches
---------------------------
We saw above that "origin" is just a shortcut to refer to the
-repository which you originally cloned from. This information is
+repository that you originally cloned from. This information is
stored in git configuration variables, which you can see using
gitlink:git-config[1]:
@@ -2407,7 +2404,7 @@ conflicts between different tree objects, allowing each pathname to be
associated with sufficient information about the trees involved that
you can create a three-way merge between them.'
-Those are the three ONLY things that the directory cache does. It's a
+Those are the ONLY three things that the directory cache does. It's a
cache, and the normal operation is to re-generate it completely from a
known tree object, or update/compare it with a live tree that is being
developed. If you blow the directory cache away entirely, you generally
From ae648606220c55074dfa12d1a11f60e62a7254ac Mon Sep 17 00:00:00 2001
From: Aneesh Kumar <aneesh.kumar@gmail.com>
Date: Mon, 26 Feb 2007 14:01:57 +0530
Subject: [PATCH 5/7] blameview: Fix the browse behavior in blameview
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
contrib/blameview/blameview.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/blameview/blameview.perl b/contrib/blameview/blameview.perl
index a9a509feb..1dec00137 100755
--- a/contrib/blameview/blameview.perl
+++ b/contrib/blameview/blameview.perl
@@ -41,7 +41,7 @@
$fileview->signal_connect (row_activated => sub {
my ($sl, $path, $column) = @_;
my $row_ref = $sl->get_row_data_from_path ($path);
- system("blameview @$row_ref[0] $fn &");
+ system("blameview @$row_ref[0]~1 $fn &");
});
my $commitwindow = Gtk2::ScrolledWindow->new();
From a91d49cd369ac5fc8e1a17357a975d09cf6c8cb3 Mon Sep 17 00:00:00 2001
From: "Shawn O. Pearce" <spearce@spearce.org>
Date: Tue, 27 Feb 2007 23:47:19 -0500
Subject: [PATCH 6/7] index-pack: Loop over pread until data loading is
complete.
A filesystem might not be able to completely supply our pread
request in one system call, such as if we are reading data from a
network file system and the requested length is just simply huge.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
index-pack.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index 72e096241..f9177442a 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -277,13 +277,19 @@ static void *get_data_from_pack(struct object_entry *obj)
{
unsigned long from = obj[0].offset + obj[0].hdr_size;
unsigned long len = obj[1].offset - from;
+ unsigned long rdy = 0;
unsigned char *src, *data;
z_stream stream;
int st;
src = xmalloc(len);
- if (pread(pack_fd, src, len, from) != len)
- die("cannot pread pack file: %s", strerror(errno));
+ data = src;
+ do {
+ ssize_t n = pread(pack_fd, data + rdy, len - rdy, from + rdy);
+ if (n <= 0)
+ die("cannot pread pack file: %s", strerror(errno));
+ rdy += n;
+ } while (rdy < len);
data = xmalloc(obj->size);
memset(&stream, 0, sizeof(stream));
stream.next_out = data;
From 163d7b9b8536d206eda7eb0eccb0fc211812346f Mon Sep 17 00:00:00 2001
From: Michael Coleman <tutufan@gmail.com>
Date: Tue, 27 Feb 2007 23:44:42 -0600
Subject: [PATCH 7/7] builtin-fmt-merge-msg: fix bugs in --file option
If --file's argument is missing, don't crash. If it cannot be opened,
die with an error message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-fmt-merge-msg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index 87d3d63ec..5be6fb438 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -259,13 +259,15 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
else if (!strcmp(argv[1], "--no-summary"))
merge_summary = 0;
else if (!strcmp(argv[1], "-F") || !strcmp(argv[1], "--file")) {
- if (argc < 2)
+ if (argc < 3)
die ("Which file?");
if (!strcmp(argv[2], "-"))
in = stdin;
else {
fclose(in);
in = fopen(argv[2], "r");
+ if (!in)
+ die("cannot open %s", argv[2]);
}
argc--; argv++;
} else