зеркало из https://github.com/microsoft/git.git
Merge branch 'maint'
* maint: builtin-fmt-merge-msg: fix bugs in --file option index-pack: Loop over pread until data loading is complete. blameview: Fix the browse behavior in blameview Fix minor typos/grammar in user-manual.txt Correct ordering in git-cvsimport's option documentation git-show: Reject native ref Fix git-show man page formatting in the EXAMPLES section
This commit is contained in:
Коммит
c4f8f82755
|
@ -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>
|
||||
|
|
|
@ -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`.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -41,7 +41,7 @@ $fileview->set_rules_hint(1);
|
|||
$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();
|
||||
|
|
|
@ -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)
|
||||
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;
|
||||
|
|
|
@ -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,
|
||||
|
|
Загрузка…
Ссылка в новой задаче