Sync with 1.7.12.1
This commit is contained in:
commit
3c7d50979a
@ -85,6 +85,12 @@ Fixes since v1.7.12
|
||||
rely on being able to parse "ls-files -s | while read a b c..."
|
||||
started to fail. Protect them from such a misconfiguration.
|
||||
|
||||
* The attribute system may be asked for a path that itself or its
|
||||
leading directories no longer exists in the working tree, and it is
|
||||
fine if we cannot open .gitattribute file in such a case. Failure
|
||||
to open per-directory .gitattributes with error status other than
|
||||
ENOENT and ENOTDIR should be diagnosed, but it wasn't.
|
||||
|
||||
* After "gitk" showed the contents of a tag, neither "Reread
|
||||
references" nor "Reload" did not update what is shown as the
|
||||
contents of it, when the user overwrote the tag with "git tag -f".
|
||||
@ -92,6 +98,9 @@ Fixes since v1.7.12
|
||||
* "ciabot" script (in contrib/) has been updated with extensive
|
||||
documentation.
|
||||
|
||||
* "git-jump" script (in contrib/) did not work well when
|
||||
diff.noprefix or diff.mnemonicprefix is in effect.
|
||||
|
||||
* Older parts of the documentation described as if having a regular
|
||||
file in .git/refs/ hierarchy were the only way to have branches and
|
||||
tags, which is not true for quite some time.
|
||||
@ -121,3 +130,5 @@ Fixes since v1.7.12
|
||||
branch name is a parameter to the option, but the heading for the
|
||||
option description was "-B::", not "-B branch::", making the
|
||||
documentation misleading.
|
||||
|
||||
Also contains numerous documentation updates.
|
||||
|
@ -39,6 +39,10 @@ OPTIONS
|
||||
See ``Date Formats'' below for details about which formats
|
||||
are supported, and their syntax.
|
||||
|
||||
-- done::
|
||||
Terminate with error if there is no 'done' command at the
|
||||
end of the stream.
|
||||
|
||||
--force::
|
||||
Force updating modified existing branches, even if doing
|
||||
so would cause commits to be lost (as the new commit does
|
||||
@ -1047,7 +1051,9 @@ done::
|
||||
Error out if the stream ends without a 'done' command.
|
||||
Without this feature, errors causing the frontend to end
|
||||
abruptly at a convenient point in the stream can go
|
||||
undetected.
|
||||
undetected. This may occur, for example, if an import
|
||||
front end dies in mid-operation without emitting SIGTERM
|
||||
or SIGKILL at its subordinate git fast-import instance.
|
||||
|
||||
`option`
|
||||
~~~~~~~~
|
||||
|
@ -304,6 +304,11 @@ committed a merge between P1 and P2, it will be propagated properly
|
||||
and all children of the merge will become merge commits with P1,P2
|
||||
as their parents instead of the merge commit.
|
||||
|
||||
*NOTE* the changes introduced by the commits, and which are not reverted
|
||||
by subsequent commits, will still be in the rewritten branch. If you want
|
||||
to throw out _changes_ together with the commits, you should use the
|
||||
interactive mode of 'git rebase'.
|
||||
|
||||
You can rewrite the commit log messages using `--msg-filter`. For
|
||||
example, 'git svn-id' strings in a repository created by 'git svn' can
|
||||
be removed this way:
|
||||
@ -314,11 +319,6 @@ git filter-branch --msg-filter '
|
||||
'
|
||||
-------------------------------------------------------
|
||||
|
||||
To restrict rewriting to only part of the history, specify a revision
|
||||
range in addition to the new branch name. The new branch name will
|
||||
point to the top-most revision that a 'git rev-list' of this range
|
||||
will print.
|
||||
|
||||
If you need to add 'Acked-by' lines to, say, the last 10 commits (none
|
||||
of which is a merge), use this command:
|
||||
|
||||
@ -329,11 +329,10 @@ git filter-branch --msg-filter '
|
||||
' HEAD~10..HEAD
|
||||
--------------------------------------------------------
|
||||
|
||||
*NOTE* the changes introduced by the commits, and which are not reverted
|
||||
by subsequent commits, will still be in the rewritten branch. If you want
|
||||
to throw out _changes_ together with the commits, you should use the
|
||||
interactive mode of 'git rebase'.
|
||||
|
||||
To restrict rewriting to only part of the history, specify a revision
|
||||
range in addition to the new branch name. The new branch name will
|
||||
point to the top-most revision that a 'git rev-list' of this range
|
||||
will print.
|
||||
|
||||
Consider this history:
|
||||
|
||||
|
@ -43,9 +43,10 @@ unreleased) version of git, that is available from 'master'
|
||||
branch of the `git.git` repository.
|
||||
Documentation for older releases are available here:
|
||||
|
||||
* link:v1.7.12/git.html[documentation for release 1.7.12]
|
||||
* link:v1.7.12.1/git.html[documentation for release 1.7.12.1]
|
||||
|
||||
* release notes for
|
||||
link:RelNotes/1.7.12.1.txt[1.7.12.1],
|
||||
link:RelNotes/1.7.12.txt[1.7.12].
|
||||
|
||||
* link:v1.7.11.7/git.html[documentation for release 1.7.11.7]
|
||||
|
@ -259,8 +259,10 @@ a positive depth, this step is skipped.
|
||||
----
|
||||
|
||||
If the client has requested a positive depth, the server will compute
|
||||
the set of commits which are no deeper than the desired depth, starting
|
||||
at the client's wants. The server writes 'shallow' lines for each
|
||||
the set of commits which are no deeper than the desired depth. The set
|
||||
of commits start at the client's wants.
|
||||
|
||||
The server writes 'shallow' lines for each
|
||||
commit whose parents will not be sent as a result. The server writes
|
||||
an 'unshallow' line for each commit which the client has indicated is
|
||||
shallow, but is no longer shallow at the currently requested depth
|
||||
|
Loading…
Reference in New Issue
Block a user