- 13 9月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 9月, 2011 2 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Sverre Rabbelier 提交于
Removing Cogito leaves just git and StGit, which is a rather incomplete list of git diff tools available. Sidestep the problem of deciding what tools to mention by not mentioning any. Signed-off-by: NSverre Rabbelier <srabbelier@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 9月, 2011 2 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
This reverts commit ffa69e61, reversing changes made to 4a13c4d1. Adding a new command line option to receive-pack and feed it from send-pack is not an acceptable way to add features, as there is no guarantee that your updated send-pack will be talking to updated receive-pack. New features need to be added via the capability mechanism negotiated over the protocol. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 8月, 2011 1 次提交
-
-
由 Thomas Rast 提交于
'git log -- <path>' does not "show commits that affect the specified paths" in a literal sense unless --full-history is given (for example, a file that only existed on a side branch will turn up no commits at all!). Reword it to specify the actual intent of the filtering, and point to the "History Simplification" section. Signed-off-by: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 8月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 8月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 8月, 2011 1 次提交
-
-
由 Heiko Voigt 提交于
Signed-off-by: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 8月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 8月, 2011 2 次提交
-
-
由 Emilio G. Cota 提交于
user-manual.pdf is not removed by `make clean'; fix it. Signed-off-by: NEmilio G. Cota <cota@braap.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Emilio G. Cota 提交于
user-manual.pdf is generated by the build and therefore should be ignored by git. Signed-off-by: NEmilio G. Cota <cota@braap.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 8月, 2011 3 次提交
-
-
由 Heiko Voigt 提交于
If the author forgets the gitignore entry the built result will show up as new file in the git working directory. Signed-off-by: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
The new wording makes it clearer that such a beast is an attribute in addition to being a macro (as opposed to being only a macro that is used for attributes). Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
In particular, make it clear that attribute macros are themselves recorded as attributes in addition to setting other attributes. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 8月, 2011 2 次提交
-
-
由 Clemens Buchacher 提交于
Currently, git push --quiet produces some non-error output, e.g.: $ git push --quiet Unpacking objects: 100% (3/3), done. Add the --quiet option to send-pack/receive-pack and pass it to unpack-objects in the receive-pack codepath and to receive-pack in the push codepath. This fixes a bug reported for the fedora git package: https://bugzilla.redhat.com/show_bug.cgi?id=725593Reported-by: NJesse Keating <jkeating@redhat.com> Cc: Todd Zullinger <tmz@pobox.com> Signed-off-by: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Carlos Martín Nieto 提交于
When the entry_count is -1, the tree is invalidated and therefore has not associated hash (or object name). Explicitly state that the next entry starts after the newline. Signed-off-by: NCarlos Martín Nieto <cmn@elego.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 7月, 2011 2 次提交
-
-
由 Dmitry Ivankov 提交于
The "notemodify" fast-import command was introduced in commit a8dd2e7d (fast-import: Add support for importing commit notes, 2009-10-09) The commit log has slightly different description than the added documentation. The latter is somewhat confusing. "notemodify" is a subcommand of "commit" command used to add a note for some commit. Does this note annotate the commit produced by the "commit" command or a commit given by it's committish parameter? Which notes tree does it write notes to? The exact meaning could be deduced with old description and some notes machinery knowledge. But let's make it more obvious. This command is used in a context like "commit refs/notes/test" to add or rewrite an annotation for a committish parameter. So the advised way to add notes in a fast-import stream is: 1) import some commits (optional) 2) prepare a "commit" to the notes tree: 2.1) choose notes ref, committer, log message, etc. 2.2) create annotations with "notemodify", where each can refer to a commit being annotated via a branch name, import mark reference, sha1 and other expressions specified in the Documentation. Signed-off-by: NDmitry Ivankov <divanorama@gmail.com> Acked-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jack Nagel 提交于
Signed-off-by: NJack Nagel <jacknagel@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 7月, 2011 1 次提交
-
-
由 Peter Collingbourne 提交于
Make it clear that git-filter-branch will honor and make permanent replacement refs as well as grafts. Signed-off-by: NPeter Collingbourne <peter@pcc.me.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 7月, 2011 1 次提交
-
-
由 Martin von Zweigbergk 提交于
The description for 'git rebase --abort' currently says: Restore the original branch and abort the rebase operation. The "restore" can be misinterpreted to imply that the original branch was somehow in a broken state during the rebase operation. It is also not completely clear what "the original branch" is --- is it the branch that was checked out before the rebase operation was called or is the the branch that is being rebased (it is the latter)? Although both issues are made clear in the DESCRIPTION section, let us also make the entry in the OPTIONS secion more clear. Also remove the term "rebasing process" from the usage text, since the user already knows that the text is about "git rebase". Signed-off-by: NMartin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 7月, 2011 1 次提交
-
-
由 Bert Wesarg 提交于
The documentation for logging updates in git-update-ref, doesn't make it clear that only a specific subset of refs are honored by this variable. Signed-off-by: NBert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 7月, 2011 2 次提交
-
-
由 Martin von Zweigbergk 提交于
The SYNOPSIS sections of most commands that span several lines already use [verse] to retain line breaks. Most commands that don't span several lines seem not to use [verse]. In the HTML output, [verse] does not only preserve line breaks, but also makes the section indented, which causes a slight inconsistency between commands that use [verse] and those that don't. Use [verse] in all SYNOPSIS sections for consistency. Also remove the blank lines from git-fetch.txt and git-rebase.txt to align with the other man pages. In the case of git-rebase.txt, which already uses [verse], the blank line makes the [verse] not apply to the last line, so removing the blank line also makes the formatting within the document more consistent. While at it, add single quotes to 'git cvsimport' for consistency with other commands. Signed-off-by: NMartin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
This has been there since textconv existed, but was never documented. There is some overlap with what's in gitattributes(5), but it's important to warn in both places that textconv diffs probably can't be applied. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 6月, 2011 2 次提交
-
-
由 Jonathan Nieder 提交于
As explained in v1.7.3-rc0~13^2 (Work around em-dash handling in newer AsciiDoc, 2010-08-23), if double dashes in names of commands are not escaped, AsciiDoc renders them as em dashes. While fixing that, spell the command name as "git sh-i18n--envsubst" (2 words) instead of emphasizing the name of the binary (one hyphenated name) and format it in italics. The double-dash in the title should be escaped, too, to avoid spurious em dashes in the header: .TH "GIT\-SH\-I18N\(emENVSUB" "1" "06/26/2011" "Git 1\&.7\&.6" "Git Manual" AsciiDoc 8.6.4 with DocBook XSL 1.76.0-RC1 copes fine and writes "GIT\-SH\-I18N\-\-ENVSUB" even without this change, which is why it was missed before. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Acked-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
AsciiDoc versions since 5.0.6 treat a double-dash surrounded by spaces (outside of verbatim environments) as a request to insert an em dash. Such versions also treat the three-character sequence "\--", when not followed by another dash, as a request to insert two literal minus signs. Thus from time to time there have been patches to add backslashes to AsciiDoc markup to escape double-dashes that are meant to be represent '--' characters used literally on the command line; see v1.4.0-rc1~174, Fix up docs where "--" isn't displayed correctly, 2006-05-05, for example. AsciiDoc 6.0.3 (2005-04-20) made life harder by also treating double-dashes without surrounding whitespace as markup for an em dash, though only when formatting for backends other than the manpages (e.g., HTML). Many pages needed to be changed to use a backslash before the "--" in names of command-line flags like "--add" (see v0.99.6~37, Update tutorial, 2005-08-30). AsciiDoc 8.3.0 (2008-11-29) refined the em-dash rule to avoid that requirement. Double-dashes without surrounding spaces are not rendered as em dashes any more unless bordered on both sides by alphanumeric characters. The unescaped markup for option names (e.g., "--add") works fine, and many instances of this style have leaked into Documentation/; git's HTML documentation contains many spurious em dashes when formatted by an older toolchain. (This patch will not change that.) The upshot: "--" as an isolated word and in phrases like "git web--browse" must be escaped if it is not to be rendered as an em dash by current asciidoc. Use "\--" to avoid such misformatting in sentences in which "--" represents a literal double-minus command line argument that separates options and revs from pathspecs, and use "{litdd}" in cases where the double-dash is embedded in the command name. The latter is just for consistency with v1.7.3-rc0~13^2 (Work around em-dash handling in newer AsciiDoc, 2010-08-23). List of lines to fix found by grepping manpages for "(em". Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Improved-by: NJunio C Hamano <gitster@pobox.com> Improved-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 6月, 2011 2 次提交
-
-
由 Junio C Hamano 提交于
Earlier 33f072f8 (submodule sync: Update "submodule.<name>.url" for empty directories, 2010-10-08) attempted to fix a bug where "git submodule sync" command does not update the URL if the current superproject does not have a checkout of the submodule. However, it did so by unconditionally registering submodule.$name.url to every submodule in the project, even the ones that the user has never showed interest in at all by running 'git submodule init' command. This caused subsequent 'git submodule update' to start cloning/updating submodules that are not interesting to the user at all. Update the code so that the URL is updated from the .gitmodules file only for submodules that already have submodule.$name.url entries, i.e. the ones the user has showed interested in having a checkout. Acked-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 6月, 2011 6 次提交
-
-
由 Junio C Hamano 提交于
HEAD on a branch does reference a commit via the branch ref it refers to. The main difference of a detached HEAD is that it _directly_ refers to a commit. Clarify this. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Reword them to avoid sounding as if loose refs are the only ones in the world. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
It is an unimportant implementation detail that ref namespaces are implemented as subdirectories of $GIT_DIR/refs. What is more important is that tags are in refs/tags hierarchy in the ref namespace. Also note that a tag can point at an object of arbitrary type, not limited to commit. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
It is an unimportant implementation detail that branches and tags are stored somewhere under $GIT_DIR/refs directory, or the name of the commit that will become the parent of the next commit is stored in $GIT_DIR/HEAD. What is more important is that branches live in refs/heads and tags live in refs/tags hierarchy in the ref namespace, and HEAD means the tip of the current branch. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
It is an unimportant implementation detail that branches and tags are stored somewhere under $GIT_DIR/refs directory. What is more important is that branches live in refs/heads and tags live in refs/tags hierarchy in the ref namespace. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
It was correct to say "The file $GIT_DIR/refs/heads/master stores the commit object name at the tip of the master branch" in the older days, but not anymore, as refs can be packed into $GIT_DIR/packed-refs file. Update the document to talk in terms of a more abstract concept "ref" and "symbolic ref" where we are not describing the underlying implementation detail. This on purpose leaves two instances of $GIT_DIR/ in the git-remote documentation; they do talk about $GIT_DIR/remotes/ and $GIT_DIR/branches/ file hierarchy that used to be the place to store configuration around remotes before the configuration mechanism took them over. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 6月, 2011 2 次提交
-
-
由 Namhyung Kim 提交于
$GIT_DIR/remotes/<name>/<branch> should be $GIT_DIR/refs/remotes/<name>/<branch>. Signed-off-by: NNamhyung Kim <namhyung@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christof Krüger 提交于
Fix documentation on "git diff --check" by adopting the description from "git apply --whitespace". Signed-off-by: NChristof Krüger <git@christof-krueger.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 6月, 2011 1 次提交
-
-
由 Jeff King 提交于
Until now, "git tag -l foo* bar*" would silently ignore the second argument, showing only refs starting with "foo". It's not just unfriendly not to take a second pattern; we actually generated subtly wrong results (from the user's perspective) because some of the requested tags were omitted. This patch allows an arbitrary number of patterns on the command line; if any of them matches, the ref is shown. While we're tweaking the documentation, let's also make it clear that the pattern is fnmatch. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 6月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 6月, 2011 2 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Alex Neronskiy 提交于
Explain the exchange that occurs between a client and server when the client is requesting shallow history and/or is already using a shallow repository. Signed-off-by: NAlex Neronskiy <zakmagnus@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-