diff options
Diffstat (limited to 'Documentation')
86 files changed, 3136 insertions, 562 deletions
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 894546d..2dd35bd 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -1,5 +1,5 @@ Like other projects, we also have some guidelines to keep to the -code. For Git in general, three rough rules are: +code. For Git in general, a few rough rules are: - Most importantly, we never say "It's in POSIX; we'll happily ignore your needs should your system not conform to it." @@ -413,6 +413,29 @@ Error Messages - Say what the error is first ("cannot open %s", not "%s: cannot open") +Externally Visible Names + + - For configuration variable names, follow the existing convention: + + . The section name indicates the affected subsystem. + + . The subsection name, if any, indicates which of an unbounded set + of things to set the value for. + + . The variable name describes the effect of tweaking this knob. + + The section and variable names that consist of multiple words are + formed by concatenating the words without punctuations (e.g. `-`), + and are broken using bumpyCaps in documentation as a hint to the + reader. + + When choosing the variable namespace, do not use variable name for + specifying possibly unbounded set of things, most notably anything + an end user can freely come up with (e.g. branch names). Instead, + use subsection names or variable values, like the existing variable + branch.<name>.description does. + + Writing Documentation: Most (if not all) of the documentation pages are written in the diff --git a/Documentation/Makefile b/Documentation/Makefile index cea0e7a..3e39e28 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -5,6 +5,7 @@ MAN7_TXT = TECH_DOCS = ARTICLES = SP_ARTICLES = +OBSOLETE_HTML = MAN1_TXT += $(filter-out \ $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ @@ -26,6 +27,7 @@ MAN7_TXT += gitcore-tutorial.txt MAN7_TXT += gitcredentials.txt MAN7_TXT += gitcvs-migration.txt MAN7_TXT += gitdiffcore.txt +MAN7_TXT += giteveryday.txt MAN7_TXT += gitglossary.txt MAN7_TXT += gitnamespaces.txt MAN7_TXT += gitrevisions.txt @@ -37,11 +39,11 @@ MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT)) MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT)) -OBSOLETE_HTML = git-remote-helpers.html +OBSOLETE_HTML += everyday.html +OBSOLETE_HTML += git-remote-helpers.html DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML) ARTICLES += howto-index -ARTICLES += everyday ARTICLES += git-tools ARTICLES += git-bisect-lk2009 # with their own formatting rules. @@ -97,6 +99,13 @@ man7dir = $(mandir)/man7 ASCIIDOC = asciidoc ASCIIDOC_EXTRA = +ASCIIDOC_HTML = xhtml11 +ASCIIDOC_DOCBOOK = docbook +ASCIIDOC_CONF = -f asciidoc.conf +ASCIIDOC_COMMON = $(ASCIIDOC) $(ASCIIDOC_EXTRA) $(ASCIIDOC_CONF) \ + -agit_version=$(GIT_VERSION) +TXT_TO_HTML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_HTML) +TXT_TO_XML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_DOCBOOK) MANPAGE_XSL = manpage-normal.xsl XMLTO = xmlto XMLTO_EXTRA = @@ -304,14 +313,12 @@ clean: $(MAN_HTML): %.html : %.txt asciidoc.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + $(TXT_TO_HTML) -d manpage -o $@+ $< && \ mv $@+ $@ $(OBSOLETE_HTML): %.html : %.txto asciidoc.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + $(TXT_TO_HTML) -o $@+ $< && \ mv $@+ $@ manpage-base-url.xsl: manpage-base-url.xsl.in @@ -323,13 +330,12 @@ manpage-base-url.xsl: manpage-base-url.xsl.in %.xml : %.txt asciidoc.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + $(TXT_TO_XML) -d manpage -o $@+ $< && \ mv $@+ $@ user-manual.xml: user-manual.txt user-manual.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b docbook -d article -o $@+ $< && \ + $(TXT_TO_XML) -d article -o $@+ $< && \ mv $@+ $@ technical/api-index.txt: technical/api-index-skel.txt \ @@ -338,8 +344,7 @@ technical/api-index.txt: technical/api-index-skel.txt \ technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ $(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt asciidoc.conf - $(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt + $(QUIET_ASCIIDOC)$(TXT_TO_HTML) $*.txt XSLT = docbook.xsl XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css @@ -386,14 +391,15 @@ howto-index.txt: howto-index.sh $(wildcard howto/*.txt) mv $@+ $@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt - $(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 $*.txt + $(QUIET_ASCIIDOC)$(TXT_TO_HTML) $*.txt WEBDOC_DEST = /pub/software/scm/git/docs howto/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - sed -e '1,/^$$/d' $< | $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 - >$@+ && \ + sed -e '1,/^$$/d' $< | \ + $(TXT_TO_HTML) - >$@+ && \ mv $@+ $@ install-webdoc : html diff --git a/Documentation/RelNotes/1.8.5.6.txt b/Documentation/RelNotes/1.8.5.6.txt new file mode 100644 index 0000000..92ff92b --- /dev/null +++ b/Documentation/RelNotes/1.8.5.6.txt @@ -0,0 +1,34 @@ +Git v1.8.5.6 Release Notes +========================== + +Fixes since v1.8.5.5 +-------------------- + + * We used to allow committing a path ".Git/config" with Git that is + running on a case sensitive filesystem, but an attempt to check out + such a path with Git that runs on a case insensitive filesystem + would have clobbered ".git/config", which is definitely not what + the user would have expected. Git now prevents you from tracking + a path with ".Git" (in any case combination) as a path component. + + * On Windows, certain path components that are different from ".git" + are mapped to ".git", e.g. "git~1/config" is treated as if it were + ".git/config". HFS+ has a similar issue, where certain unicode + codepoints are ignored, e.g. ".g\u200cit/config" is treated as if + it were ".git/config". Pathnames with these potential issues are + rejected on the affected systems. Git on systems that are not + affected by this issue (e.g. Linux) can also be configured to + reject them to ensure cross platform interoperability of the hosted + projects. + + * "git fsck" notices a tree object that records such a path that can + be confused with ".git", and with receive.fsckObjects configuration + set to true, an attempt to "git push" such a tree object will be + rejected. Such a path may not be a problem on a well behaving + filesystem but in order to protect those on HFS+ and on case + insensitive filesystems, this check is enabled on all platforms. + +A big "thanks!" for bringing this issue to us goes to our friends in +the Mercurial land, namely, Matt Mackall and Augie Fackler. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/1.9.5.txt b/Documentation/RelNotes/1.9.5.txt new file mode 100644 index 0000000..8d6ac0c --- /dev/null +++ b/Documentation/RelNotes/1.9.5.txt @@ -0,0 +1,34 @@ +Git v1.9.5 Release Notes +======================== + +Fixes since v1.9.4 +------------------ + + * We used to allow committing a path ".Git/config" with Git that is + running on a case sensitive filesystem, but an attempt to check out + such a path with Git that runs on a case insensitive filesystem + would have clobbered ".git/config", which is definitely not what + the user would have expected. Git now prevents you from tracking + a path with ".Git" (in any case combination) as a path component. + + * On Windows, certain path components that are different from ".git" + are mapped to ".git", e.g. "git~1/config" is treated as if it were + ".git/config". HFS+ has a similar issue, where certain unicode + codepoints are ignored, e.g. ".g\u200cit/config" is treated as if + it were ".git/config". Pathnames with these potential issues are + rejected on the affected systems. Git on systems that are not + affected by this issue (e.g. Linux) can also be configured to + reject them to ensure cross platform interoperability of the hosted + projects. + + * "git fsck" notices a tree object that records such a path that can + be confused with ".git", and with receive.fsckObjects configuration + set to true, an attempt to "git push" such a tree object will be + rejected. Such a path may not be a problem on a well behaving + filesystem but in order to protect those on HFS+ and on case + insensitive filesystems, this check is enabled on all platforms. + +A big "thanks!" for bringing this issue to us goes to our friends in +the Mercurial land, namely, Matt Mackall and Augie Fackler. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.0.5.txt b/Documentation/RelNotes/2.0.5.txt new file mode 100644 index 0000000..3a16f69 --- /dev/null +++ b/Documentation/RelNotes/2.0.5.txt @@ -0,0 +1,34 @@ +Git v2.0.5 Release Notes +======================== + +Fixes since v2.0.4 +------------------ + + * We used to allow committing a path ".Git/config" with Git that is + running on a case sensitive filesystem, but an attempt to check out + such a path with Git that runs on a case insensitive filesystem + would have clobbered ".git/config", which is definitely not what + the user would have expected. Git now prevents you from tracking + a path with ".Git" (in any case combination) as a path component. + + * On Windows, certain path components that are different from ".git" + are mapped to ".git", e.g. "git~1/config" is treated as if it were + ".git/config". HFS+ has a similar issue, where certain unicode + codepoints are ignored, e.g. ".g\u200cit/config" is treated as if + it were ".git/config". Pathnames with these potential issues are + rejected on the affected systems. Git on systems that are not + affected by this issue (e.g. Linux) can also be configured to + reject them to ensure cross platform interoperability of the hosted + projects. + + * "git fsck" notices a tree object that records such a path that can + be confused with ".git", and with receive.fsckObjects configuration + set to true, an attempt to "git push" such a tree object will be + rejected. Such a path may not be a problem on a well behaving + filesystem but in order to protect those on HFS+ and on case + insensitive filesystems, this check is enabled on all platforms. + +A big "thanks!" for bringing this issue to us goes to our friends in +the Mercurial land, namely, Matt Mackall and Augie Fackler. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.1.4.txt b/Documentation/RelNotes/2.1.4.txt new file mode 100644 index 0000000..d16e5f0 --- /dev/null +++ b/Documentation/RelNotes/2.1.4.txt @@ -0,0 +1,34 @@ +Git v2.1.4 Release Notes +======================== + +Fixes since v2.1.3 +------------------ + + * We used to allow committing a path ".Git/config" with Git that is + running on a case sensitive filesystem, but an attempt to check out + such a path with Git that runs on a case insensitive filesystem + would have clobbered ".git/config", which is definitely not what + the user would have expected. Git now prevents you from tracking + a path with ".Git" (in any case combination) as a path component. + + * On Windows, certain path components that are different from ".git" + are mapped to ".git", e.g. "git~1/config" is treated as if it were + ".git/config". HFS+ has a similar issue, where certain unicode + codepoints are ignored, e.g. ".g\u200cit/config" is treated as if + it were ".git/config". Pathnames with these potential issues are + rejected on the affected systems. Git on systems that are not + affected by this issue (e.g. Linux) can also be configured to + reject them to ensure cross platform interoperability of the hosted + projects. + + * "git fsck" notices a tree object that records such a path that can + be confused with ".git", and with receive.fsckObjects configuration + set to true, an attempt to "git push" such a tree object will be + rejected. Such a path may not be a problem on a well behaving + filesystem but in order to protect those on HFS+ and on case + insensitive filesystems, this check is enabled on all platforms. + +A big "thanks!" for bringing this issue to us goes to our friends in +the Mercurial land, namely, Matt Mackall and Augie Fackler. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.2.0.txt b/Documentation/RelNotes/2.2.0.txt new file mode 100644 index 0000000..e98ecbc --- /dev/null +++ b/Documentation/RelNotes/2.2.0.txt @@ -0,0 +1,313 @@ +Git v2.2 Release Notes +====================== + +Updates since v2.1 +------------------ + +Ports + + * Building on older MacOS X systems automatically sets + the necessary NO_APPLE_COMMON_CRYPTO build-time option. + + * Building with NO_PTHREADS has been resurrected. + + * Compilation options have been updated a bit to better support the + z/OS port. + + +UI, Workflows & Features + + * "git archive" learned to filter what gets archived with a pathspec. + + * "git config --edit --global" starts from a skeletal per-user + configuration file contents, instead of a total blank, when the + user does not already have any global config. This immediately + reduces the need to later ask "Have you forgotten to set + core.user?", and we can add more to the template as we gain + more experience. + + * "git stash list -p" used to be almost always a no-op because each + stash entry is represented as a merge commit. It learned to show + the difference between the base commit version and the working tree + version, which is in line with what "git stash show" gives. + + * Sometimes users want to report a bug they experience on their + repository, but they are not at liberty to share the contents of + the repository. "fast-export" was taught an "--anonymize" option + to replace blob contents, names of people, paths and log + messages with bland and simple strings to help them. + + * "git difftool" learned an option to stop feeding paths to the + diff backend when it exits with a non-zero status. + + * "git grep" learned to paint (or not paint) partial matches on + context lines when showing "grep -C<num>" output in color. + + * "log --date=iso" uses a slight variant of the ISO 8601 format that is + more human readable. A new "--date=iso-strict" option gives + datetime output that conforms more strictly. + + * The logic "git prune" uses is more resilient against various corner + cases. + + * A broken reimplementation of Git could write an invalid index that + records both stage #0 and higher-stage entries for the same path. + We now notice and reject such an index, as there is no sensible + fallback (we do not know if the broken tool wanted to resolve and + forgot to remove the higher-stage entries, or if it wanted to unresolve + and forgot to remove the stage #0 entry). + + * The temporary files "git mergetool" uses are renamed to avoid too + many dots in them (e.g. a temporary file for "hello.c" used to be + named e.g. "hello.BASE.4321.c" but now uses underscore instead, + e.g. "hello_BASE_4321.c", to allow us to have multiple variants). + + * The temporary files "git mergetool" uses can be placed in a newly + created temporary directory, instead of the current directory, by + setting the mergetool.writeToTemp configuration variable. + + * "git mergetool" understands "--tool bc" now, as version 4 of + BeyondCompare can be driven the same way as its version 3 and it + feels awkward to say "--tool bc3" to run version 4. + + * The "pre-receive" and "post-receive" hooks are no longer required + to consume their input fully (not following this requirement used + to result in intermittent errors in "git push"). + + * The pretty-format specifier "%d", which expands to " (tagname)" + for a tagged commit, gained a cousin "%D" that just gives the + "tagname" without frills. + + * "git push" learned "--signed" push, that allows a push (i.e. + request to update the refs on the other side to point at a new + history, together with the transmission of necessary objects) to be + signed, so that it can be verified and audited, using the GPG + signature of the person who pushed, that the tips of branches at a + public repository really point the commits the pusher wanted to, + without having to "trust" the server. + + * "git interpret-trailers" is a new filter to programmatically edit + the tail end of the commit log messages, e.g. "Signed-off-by:". + + * "git help everyday" shows the "Everyday Git in 20 commands or so" + document, whose contents have been updated to match more modern + Git practice. + + * On the "git svn" front, work progresses to reduce memory consumption and + to improve handling of mergeinfo. + + +Performance, Internal Implementation, Development Support etc. + + * The API to manipulate the "refs" has been restructured to make it + more transactional, with the eventual goal to allow all-or-none + atomic updates and migrating the storage to something other than + the traditional filesystem based one (e.g. databases). + + * The lockfile API and its users have been cleaned up. + + * We no longer attempt to keep track of individual dependencies to + the header files in the build procedure, relying instead on automated + dependency generation support from modern compilers. + + * In tests, we have been using NOT_{MINGW,CYGWIN} test prerequisites + long before negated prerequisites e.g. !MINGW were invented. + The former has been converted to the latter to avoid confusion. + + * Optimized looking up a remote's configuration in a repository with very many + remotes defined. + + * There are cases where you lock and open to write a file, close it + to show the updated contents to an external processes, and then have + to update the file again while still holding the lock; now the + lockfile API has support for such an access pattern. + + * The API to allocate the structure to keep track of commit + decoration has been updated to make it less cumbersome to use. + + * An in-core caching layer to let us avoid reading the same + configuration files several times has been added. A few commands + have been converted to use this subsystem. + + * Various code paths have been cleaned up and simplified by using + the "strbuf", "starts_with()", and "skip_prefix()" APIs more. + + * A few codepaths that died when large blobs that would not fit in + core are involved in their operation have been taught to punt + instead, by e.g. marking a too-large blob as not to be diffed. + + * A few more code paths in "commit" and "checkout" have been taught + to repopulate the cache-tree in the index, to help speed up later + "write-tree" (used in "commit") and "diff-index --cached" (used in + "status"). + + * A common programming mistake to assign the same short option name + to two separate options is detected by the parse_options() API to help + developers. + + * The code path to write out the packed-refs file has been optimized, + which especially matters in a repository with a large number of + refs. + + * The check to see if a ref $F can be created by making sure no + existing ref has $F/ as its prefix has been optimized, which + especially matters in a repository with a large number of existing + refs. + + * "git fsck" was taught to check the contents of tag objects a bit more. + + * "git hash-object" was taught a "--literally" option to help + debugging. + + * When running a required clean filter, we do not have to mmap the + original before feeding the filter. Instead, stream the file + contents directly to the filter and process its output. + + * The scripts in the test suite can be run with the "-x" option to show + a shell-trace of each command they run. + + * The "run-command" API learned to manage the argv and environment + arrays for child process, alleviating the need for the callers to + allocate and deallocate them. + + * Some people use AsciiDoctor, instead of AsciiDoc, to format our + documentation set; the documentation has been adjusted to be usable + by both, as AsciiDoctor is pickier than AsciiDoc about its input + mark-up. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.1 +---------------- + +Unless otherwise noted, all the fixes since v2.1 in the maintenance +track are contained in this release (see the maintenance releases' +notes for details). + + * "git log --pretty/format=" with an empty format string did not + mean the more obvious "No output whatsoever" but "Use default + format", which was counterintuitive. + + * "git -c section.var command" and "git -c section.var= command" + should pass the configuration value differently (the former should be a + boolean true, the latter should be an empty string). + + * Applying a patch not generated by Git in a subdirectory used to + check for whitespace breakage using the attributes of incorrect + paths. Also whitespace checks were performed even for paths + excluded via the "git apply --exclude=<path>" mechanism. + + * "git bundle create" with a date-range specification was meant to + exclude tags outside the range, but it didn't. + + * "git add x" where x used to be a directory and is now a + symbolic link to a directory misbehaved. + + * The prompt script checked the $GIT_DIR/ref/stash file to see if there + is a stash, which was a no-no. + + * Pack-protocol documentation had a minor typo. + + * "git checkout -m" did not switch to another branch while carrying + the local changes forward when a path was deleted from the index. + + * "git daemon" (with NO_IPV6 build configuration) used to incorrectly + use the hostname even when gethostbyname() reported that the given + hostname is not found. + (merge 107efbe rs/daemon-fixes later to maint). + + * With sufficiently long refnames, "git fast-import" could have + overflowed an on-stack buffer. + + * After "pack-refs --prune" packed refs at the top-level, it failed + to prune them. + + * Progress output from "git gc --auto" was visible in "git fetch -q". + + * We used to pass -1000 to poll(2), expecting it to also mean "no + timeout", which should be spelled as -1. + + * "git rebase" documentation was unclear that it is required to + specify on what <upstream> the rebase is to be done when telling it + to first check out <branch>. + (merge 95c6826 so/rebase-doc later to maint). + + * "git push" over HTTP transport had an artificial limit on the number of + refs that can be pushed, imposed by the command line length. + (merge 26be19b jk/send-pack-many-refspecs later to maint). + + * When receiving an invalid pack stream that records the same object + twice, multiple threads got confused due to a race. + (merge ab791dd jk/index-pack-threading-races later to maint). + + * An attempt to remove the entire tree in the "git fast-import" input + stream caused it to misbehave. + (merge 2668d69 mb/fast-import-delete-root later to maint). + + * Reachability check (used in "git prune" and friends) did not add a + detached HEAD as a starting point to traverse objects still in use. + (merge c40fdd0 mk/reachable-protect-detached-head later to maint). + + * "git config --add section.var val" when section.var already has an + empty-string value used to lose the empty-string value. + (merge c1063be ta/config-add-to-empty-or-true-fix later to maint). + + * "git fsck" failed to report that it found corrupt objects via its + exit status in some cases. + (merge 30d1038 jk/fsck-exit-code-fix later to maint). + + * Use of the "--verbose" option used to break "git branch --merged". + (merge 12994dd jk/maint-branch-verbose-merged later to maint). + + * Some MUAs mangle a line in a message that begins with "From " to + ">From " when writing to a mailbox file, and feeding such an input + to "git am" used to lose such a line. + (merge 85de86a jk/mbox-from-line later to maint). + + * "rev-parse --verify --quiet $name" is meant to quietly exit with a + non-zero status when $name is not a valid object name, but still + gave error messages in some cases. + + * A handful of C source files have been updated to include + "git-compat-util.h" as the first thing, to conform better to our + coding guidelines. + (merge 1c4b660 da/include-compat-util-first-in-c later to maint). + + * The t7004 test, which tried to run Git with small stack space, has been + updated to use a bit larger stack to avoid false breakage on some + platforms. + (merge b9a1907 sk/tag-contains-wo-recursion later to maint). + + * A few documentation pages had example sections marked up not quite + correctly, which passed AsciiDoc but failed with AsciiDoctor. + (merge c30c43c bc/asciidoc-pretty-formats-fix later to maint). + (merge f8a48af bc/asciidoc later to maint). + + * "gitweb" used deprecated CGI::startfrom, which was removed from + CGI.pm as of 4.04; use CGI::start_from instead. + (merge 4750f4b rm/gitweb-start-form later to maint). + + * Newer versions of 'meld' break the auto-detection we use to see if + they are new enough to support the `--output` option. + (merge b12d045 da/mergetool-meld later to maint). + + * "git pack-objects" forgot to disable the codepath to generate the + object reachability bitmap when it needs to split the resulting + pack. + (merge 2113471 jk/pack-objects-no-bitmap-when-splitting later to maint). + + * The code to use cache-tree trusted the on-disk data too much and + fell into an infinite loop upon seeing an incorrectly recorded + index file. + (merge 729dbbd jk/cache-tree-protect-from-broken-libgit2 later to maint). + + * "git fetch" into a repository where branch B was deleted earlier, + back when it had reflog enabled, and then branch B/C is fetched + into it without reflog enabled, which is arguably an unlikely + corner case, unnecessarily failed. + (merge aae828b jk/fetch-reflog-df-conflict later to maint). + + * "git log --first-parent -L..." used to crash. + (merge a8787c5 tm/line-log-first-parent later to maint). diff --git a/Documentation/RelNotes/2.2.1.txt b/Documentation/RelNotes/2.2.1.txt new file mode 100644 index 0000000..d5a3cd9 --- /dev/null +++ b/Documentation/RelNotes/2.2.1.txt @@ -0,0 +1,34 @@ +Git v2.2.1 Release Notes +======================== + +Fixes since v2.2 +---------------- + + * We used to allow committing a path ".Git/config" with Git that is + running on a case sensitive filesystem, but an attempt to check out + such a path with Git that runs on a case insensitive filesystem + would have clobbered ".git/config", which is definitely not what + the user would have expected. Git now prevents you from tracking + a path with ".Git" (in any case combination) as a path component. + + * On Windows, certain path components that are different from ".git" + are mapped to ".git", e.g. "git~1/config" is treated as if it were + ".git/config". HFS+ has a similar issue, where certain unicode + codepoints are ignored, e.g. ".g\u200cit/config" is treated as if + it were ".git/config". Pathnames with these potential issues are + rejected on the affected systems. Git on systems that are not + affected by this issue (e.g. Linux) can also be configured to + reject them to ensure cross platform interoperability of the hosted + projects. + + * "git fsck" notices a tree object that records such a path that can + be confused with ".git", and with receive.fsckObjects configuration + set to true, an attempt to "git push" such a tree object will be + rejected. Such a path may not be a problem on a well behaving + filesystem but in order to protect those on HFS+ and on case + insensitive filesystems, this check is enabled on all platforms. + +A big "thanks!" for bringing this issue to us goes to our friends in +the Mercurial land, namely, Matt Mackall and Augie Fackler. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.2.2.txt b/Documentation/RelNotes/2.2.2.txt new file mode 100644 index 0000000..b19a35d --- /dev/null +++ b/Documentation/RelNotes/2.2.2.txt @@ -0,0 +1,63 @@ +Git v2.2.2 Release Notes +======================== + +Fixes since v2.2.1 +------------------ + + * "git checkout $treeish $path", when $path in the index and the + working tree already matched what is in $treeish at the $path, + still overwrote the $path unnecessarily. + + * "git config --get-color" did not parse its command line arguments + carefully. + + * open() emulated on Windows platforms did not give EISDIR upon + an attempt to open a directory for writing. + + * A few code paths used abs() when they should have used labs() on + long integers. + + * "gitweb" used to depend on a behaviour recent CGI.pm deprecated. + + * "git init" (hence "git clone") initialized the per-repository + configuration file .git/config with x-bit by mistake. + + * Git 2.0 was supposed to make the "simple" mode for the default of + "git push", but it didn't. + + * "Everyday" document had a broken link. + + * The build procedure did not bother fixing perl and python scripts + when NO_PERL and NO_PYTHON build-time configuration changed. + + * The code that reads the reflog from the newer to the older entries + did not handle an entry that crosses a boundary of block it uses to + read them correctly. + + * "git apply" was described in the documentation to take --ignore-date + option, which it does not. + + * Traditionally we tried to avoid interpreting date strings given by + the user as future dates, e.g. GIT_COMMITTER_DATE=2014-12-10 when + used early November 2014 was taken as "October 12, 2014" because it + is likely that a date in the future, December 10, is a mistake. + This heuristics has been loosened to allow people to express future + dates (most notably, --until=<date> may want to be far in the + future) and we no longer tiebreak by future-ness of the date when + + (1) ISO-like format is used, and + (2) the string can make sense interpreted as both y-m-d and y-d-m. + + Git may still have to use the heuristics to tiebreak between dd/mm/yy + and mm/dd/yy, though. + + * The code to abbreviate an object name to its short unique prefix + has been optimized when no abbreviation was requested. + + * "git add --ignore-errors ..." did not ignore an error to + give a file that did not exist. + + * Git did not correctly read an overlong refname from a packed refs + file. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.0.txt b/Documentation/RelNotes/2.3.0.txt new file mode 100644 index 0000000..e3c639c --- /dev/null +++ b/Documentation/RelNotes/2.3.0.txt @@ -0,0 +1,300 @@ +Git v2.3 Release Notes +====================== + +This one ended up to be a release with lots of small corrections and +improvements without big uncomfortably exciting features. The recent +security fix that went to 2.2.1 and older maintenance tracks is also +contained in this update. + + +Updates since v2.2 +------------------ + +Ports + + * Recent gcc toolchain on Cygwin started throwing compilation warning, + which has been squelched. + + * A few updates to build on platforms that lack tv_nsec, + clock_gettime, CLOCK_MONOTONIC and HMAC_CTX_cleanup (e.g. older + RHEL) have been added. + + +UI, Workflows & Features + + * It was cumbersome to use "GIT_SSH" mechanism when the user wanted + to pass an extra set of arguments to the underlying ssh. A new + environment variable GIT_SSH_COMMAND can be used for this. + + * A request to store an empty note via "git notes" meant to remove + note from the object but with --allow-empty we will store a + (surprise!) note that is empty. + + * "git interpret-trailers" learned to properly handle the + "Conflicts:" block at the end. + + * "git am" learned "--message-id" option to copy the message ID of + the incoming e-mail to the log message of resulting commit. + + * "git clone --reference=<over there>" learned the "--dissociate" + option to go with it; it borrows objects from the reference object + store while cloning only to reduce network traffic and then + dissociates the resulting clone from the reference by performing + local copies of borrowed objects. + + * "git send-email" learned "--transfer-encoding" option to force a + non-fault Content-Transfer-Encoding header (e.g. base64). + + * "git send-email" normally identifies itself via X-Mailer: header in + the message it sends out. A new command line flag --no-xmailer + allows the user to squelch the header. + + * "git push" into a repository with a working tree normally refuses + to modify the branch that is checked out. The command learned to + optionally do an equivalent of "git reset --hard" only when there + is no change to the working tree and the index instead, which would + be useful to "deploy" by pushing into a repository. + + * "git new-workdir" (in contrib/) can be used to populate an empty + and existing directory now. + + * Credential helpers are asked in turn until one of them give + positive response, which is cumbersome to turn off when you need to + run Git in an automated setting. The credential helper interface + learned to allow a helper to say "stop, don't ask other helpers." + Also GIT_TERMINAL_PROMPT environment can be set to false to disable + our built-in prompt mechanism for passwords. + + * "git branch -d" (delete) and "git branch -m" (move) learned to + honor "-f" (force) flag; unlike many other subcommands, the way to + force these have been with separate "-D/-M" options, which was + inconsistent. + + * "diff-highlight" filter (in contrib/) allows its color output to be + customized via configuration variables. + + * "git imap-send" learned to take "-v" (verbose) and "-q" (quiet) + command line options. + + * "git remote add $name $URL" is now allowed when "url.$URL.insteadOf" + is already defined. + + * "git imap-send" now can be built to use cURL library to talk to + IMAP servers (if the library is recent enough, of course). + This allows you to use authenticate method other than CRAM-MD5, + among other things. + + * "git imap-send" now allows GIT_CURL_VERBOSE environment variable to + control the verbosity when talking via the cURL library. + + * The prompt script (in contrib/) learned to optionally hide prompt + when in an ignored directory by setting GIT_PS1_HIDE_IF_PWD_IGNORED + shell variable. + + +Performance, Internal Implementation, Development Support etc. + + * Earlier we made "rev-list --object-edge" more aggressively list the + objects at the edge commits, in order to reduce number of objects　 + fetched into a shallow repository, but the change affected cases + other than "fetching into a shallow repository" and made it + unusably slow (e.g. fetching into a normal repository should not + have to suffer the overhead from extra processing). Limit it to a + more specific case by introducing --objects-edge-aggressive, a new + option to rev-list. + + * Squelched useless compiler warnings on Mac OS X regarding the + crypto API. + + * The procedure to generate unicode table has been simplified. + + * Some filesystems assign filemodes in a strange way, fooling then + automatic "filemode trustability" check done during a new + repository creation. The initialization codepath has been hardened + against this issue. + + * The codepath in "git remote update --prune" to drop many refs has + been optimized. + + * The API into get_merge_bases*() family of functions was easy to + misuse, which has been corrected to make it harder to do so. + + * Long overdue departure from the assumption that S_IFMT is shared by + everybody made in 2005, which was necessary to port to z/OS. + + * "git push" and "git fetch" did not communicate an overlong refname + correctly. Now it uses 64kB sideband to accommodate longer ones. + + * Recent GPG changes the keyring format and drops support for RFC1991 + formatted signatures, breaking our existing tests. + + * "git-prompt" (in contrib/) used a variable from the global scope, + possibly contaminating end-user's namespace. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.2 +---------------- + +Unless otherwise noted, all the fixes since v2.2 in the maintenance +track are contained in this release (see the maintenance releases' +notes for details). + + * "git http-push" over WebDAV (aka dumb http-push) was broken in + v2.2.2 when parsing a symbolic ref, resulting in a bogus request + that gets rejected by recent versions of cURL library. + (merge f6786c8 jk/http-push-symref-fix later to maint). + + * The logic in "git bisect bad HEAD" etc. to avoid forcing the test + of the common ancestor of bad and good commits was broken. + (merge 07913d5 cc/bisect-rev-parsing later to maint). + + * "git checkout-index --temp=$target $path" did not work correctly + for paths outside the current subdirectory in the project. + (merge 74c4de5 es/checkout-index-temp later to maint). + + * The report from "git checkout" on a branch that builds on another + local branch by setting its branch.*.merge to branch name (not a + full refname) incorrectly said that the upstream is gone. + (merge 05e7368 jc/checkout-local-track-report later to maint). + + * With The git-prompt support (in contrib/), using the exit status of + the last command in the prompt, e.g. PS1='$(__git_ps1) $? ', did + not work well, because the helper function stomped on the exit + status. + (merge 6babe76 tf/prompt-preserve-exit-status later to maint). + + * Recent update to "git commit" broke amending an existing commit + with bogus author/committer lines without a valid e-mail address. + (merge c83a509 jk/commit-date-approxidate later to maint). + + * The lockfile API used to get confused which file to clean up when + the process moved the $cwd after creating a lockfile. + (merge fa137f6 nd/lockfile-absolute later to maint). + + * Traditionally we tried to avoid interpreting date strings given by + the user as future dates, e.g. GIT_COMMITTER_DATE=2014-12-10 when + used early November 2014 was taken as "October 12, 2014" because it + is likely that a date in the future, December 10, is a mistake. + This heuristics has been loosened to allow people to express future + dates (most notably, --until=<date> may want to be far in the + future) and we no longer tiebreak by future-ness of the date when + + (1) ISO-like format is used, and + (2) the string can make sense interpreted as both y-m-d and y-d-m. + + Git may still have to use the heuristics to tiebreak between dd/mm/yy + and mm/dd/yy, though. + (merge d372395 jk/approxidate-avoid-y-d-m-over-future-dates later to maint). + + * Git did not correctly read an overlong refname from a packed refs + file. + (merge ea41783 jk/read-packed-refs-without-path-max later to maint). + + * "git apply" was described in the documentation to take --ignore-date + option, which it does not. + (merge 0cef4e7 rw/apply-does-not-take-ignore-date later to maint). + + * "git add -i" did not notice when the interactive command input + stream went away and kept asking the same question. + (merge a8bec7a jk/add-i-read-error later to maint). + + * "git send-email" did not handle RFC 2047 encoded headers quite + right. + (merge ab47e2a rd/send-email-2047-fix later to maint). + + * New tag object format validation added in 2.2 showed garbage after + a tagname it reported in its error message. + (merge a1e920a js/fsck-tag-validation later to maint). + + * The code that reads the reflog from the newer to the older entries + did not handle an entry that crosses a boundary of block it uses to + read them correctly. + (merge 69216bf jk/for-each-reflog-ent-reverse later to maint). + + * "git diff -B -M" after making a new copy B out of an existing file + A and then editing A extensively ought to report that B was created + by copying A and A was modified, which is what "git diff -C" + reports, but it instead said A was renamed to B and A was edited + heavily in place. This was not just incoherent but also failed to + apply with "git apply". The report has been corrected to match what + "git diff -C" produces for this case. + (merge 6936b58 jc/diff-b-m later to maint). + + * In files we pre-populate for the user to edit with commented hints, + a line of hint that is indented with a tab used to show as '#' (or + any comment char), ' ' (space), and then the hint text that began + with the tab, which some editors flag as an indentation error (tab + following space). We now omit the space after the comment char in + such a case. + (merge d55aeb7 jc/strbuf-add-lines-avoid-sp-ht-sequence later to maint). + + * "git ls-tree" does not support path selection based on negative + pathspecs, but did not error out when negative pathspecs are given. + (merge f1f6224 nd/ls-tree-pathspec later to maint). + + * The function sometimes returned a non-freeable memory and some + other times returned a piece of memory that must be freed, leading + to inevitable leaks. + (merge 59362e5 jc/exec-cmd-system-path-leak-fix later to maint). + + * The code to abbreviate an object name to its short unique prefix + has been optimized when no abbreviation was requested. + (merge 61e704e mh/find-uniq-abbrev later to maint). + + * "git add --ignore-errors ..." did not ignore an error to + give a file that did not exist. + (merge 1d31e5a mg/add-ignore-errors later to maint). + + * "git checkout $treeish $path", when $path in the index and the + working tree already matched what is in $treeish at the $path, + still overwrote the $path unnecessarily. + (merge c5326bd jk/checkout-from-tree later to maint). + + * "git config --get-color" did not parse its command line arguments + carefully. + (merge cb35722 jk/colors-fix later to maint). + + * open() emulated on Windows platforms did not give EISDIR upon + an attempt to open a directory for writing. + (merge ba6fad0 js/windows-open-eisdir-error later to maint). + + * A few code paths used abs() when they should have used labs() on + long integers. + (merge 83915ba rs/maint-config-use-labs later to maint). + (merge 31a8aa1 rs/receive-pack-use-labs later to maint). + + * "gitweb" used to depend on a behaviour recent CGI.pm deprecated. + (merge 13dbf46 jk/gitweb-with-newer-cgi-multi-param later to maint). + + * "git init" (hence "git clone") initialized the per-repository + configuration file .git/config with x-bit by mistake. + (merge 1f32ecf mh/config-flip-xbit-back-after-checking later to maint). + + * Recent update in Git 2.2 started creating objects/info/packs and + info/refs files with permission bits tighter than user's umask. + (merge d91175b jk/prune-packed-server-info later to maint). + + * Git 2.0 was supposed to make the "simple" mode for the default of + "git push", but it didn't. + (merge 00a6fa0 jk/push-simple later to maint). + + * "Everyday" document had a broken link. + (merge 366c8d4 po/everyday-doc later to maint). + + * A few test fixes. + (merge 880ef58 jk/no-perl-tests later to maint). + + * The build procedure did not bother fixing perl and python scripts + when NO_PERL and NO_PYTHON build-time configuration changed. + (merge ca2051d jk/rebuild-perl-scripts-with-no-perl-seting-change later to maint). + + * The usage string of "git log" command was marked incorrectly for + l10n. + (merge e66dc0c km/log-usage-string-i18n later to maint). + + * "git for-each-ref" mishandled --format="%(upstream:track)" when a + branch is marked to have forked from a non-existing branch. + (merge b6160d9 rc/for-each-ref-tracking later to maint). diff --git a/Documentation/RelNotes/2.3.1.txt b/Documentation/RelNotes/2.3.1.txt new file mode 100644 index 0000000..cf96186 --- /dev/null +++ b/Documentation/RelNotes/2.3.1.txt @@ -0,0 +1,52 @@ +Git v2.3.1 Release Notes +======================== + +Fixes since v2.3 +---------------- + + * The interactive "show a list and let the user choose from it" + interface "add -i" used showed and prompted to the user even when + the candidate list was empty, against which the only "choice" the + user could have made was to choose nothing. + + * "git apply --whitespace=fix" used to under-allocate the memory + when the fix resulted in a longer text than the original patch. + + * "git log --help" used to show rev-list options that are irrelevant + to the "log" command. + + * The error message from "git commit", when a non-existing author + name was given as value to the "--author=" parameter, has been + reworded to avoid misunderstanding. + + * A broken pack .idx file in the receiving repository prevented the + dumb http transport from fetching a good copy of it from the other + side. + + * The documentation incorrectly said that C(opy) and R(ename) are the + only ones that can be followed by the score number in the output in + the --raw format. + + * Fix a misspelled conditional that is always true. + + * Code to read branch name from various files in .git/ directory + would have misbehaved if the code to write them left an empty file. + + * The "git push" documentation made the "--repo=<there>" option + easily misunderstood. + + * After attempting and failing a password-less authentication + (e.g. kerberos), libcURL refuses to fall back to password based + Basic authentication without a bit of help/encouragement. + + * Setting diff.submodule to 'log' made "git format-patch" produce + broken patches. + + * "git rerere" (invoked internally from many mergy operations) did + not correctly signal errors when told to update the working tree + files and failed to do so for whatever reason. + + * "git blame HEAD -- missing" failed to correctly say "HEAD" when it + tried to say "No such path 'missing' in HEAD". + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.2.txt b/Documentation/RelNotes/2.3.2.txt new file mode 100644 index 0000000..93462e4 --- /dev/null +++ b/Documentation/RelNotes/2.3.2.txt @@ -0,0 +1,79 @@ +Git v2.3.2 Release Notes +======================== + +Fixes since v2.3.1 +------------------ + + * "update-index --refresh" used to leak when an entry cannot be + refreshed for whatever reason. + + * "git fast-import" used to crash when it could not close and + conclude the resulting packfile cleanly. + + * "git blame" died, trying to free an uninitialized piece of memory. + + * "git merge-file" did not work correctly in a subdirectory. + + * "git submodule add" failed to squash "path/to/././submodule" to + "path/to/submodule". + + * In v2.2.0, we broke "git prune" that runs in a repository that + borrows from an alternate object store. + + * Certain older vintages of cURL give irregular output from + "curl-config --vernum", which confused our build system. + + * An earlier workaround to squelch unhelpful deprecation warnings + from the compiler on Mac OSX unnecessarily set minimum required + version of the OS, which the user might want to raise (or lower) + for other reasons. + + * Longstanding configuration variable naming rules has been added to + the documentation. + + * The credential helper for Windows (in contrib/) used to mishandle + a user name with an at-sign in it. + + * Older GnuPG implementations may not correctly import the keyring + material we prepare for the tests to use. + + * Clarify in the documentation that "remote.<nick>.pushURL" and + "remote.<nick>.URL" are there to name the same repository accessed + via different transports, not two separate repositories. + + * The pack bitmap support did not build with older versions of GCC. + + * Reading configuration from a blob object, when it ends with a lone + CR, use to confuse the configuration parser. + + * We didn't format an integer that wouldn't fit in "int" but in + "uintmax_t" correctly. + + * "git push --signed" gave an incorrectly worded error message when + the other side did not support the capability. + + * "git fetch" over a remote-helper that cannot respond to "list" + command could not fetch from a symbolic reference e.g. HEAD. + + * The insn sheet "git rebase -i" creates did not fully honor + core.abbrev settings. + + * The tests that wanted to see that file becomes unreadable after + running "chmod a-r file", and the tests that wanted to make sure it + is not run as root, we used "can we write into the / directory?" as + a cheap substitute, but on some platforms that is not a good + heuristics. The tests and their prerequisites have been updated to + check what they really require. + + * The configuration variable 'mailinfo.scissors' was hard to + discover in the documentation. + + * Correct a breakage to git-svn around v2.2 era that triggers + premature closing of FileHandle. + + * Even though we officially haven't dropped Perl 5.8 support, the + Getopt::Long package that came with it does not support "--no-" + prefix to negate a boolean option; manually add support to help + people with older Getopt::Long package. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.3.txt b/Documentation/RelNotes/2.3.3.txt new file mode 100644 index 0000000..5ef1264 --- /dev/null +++ b/Documentation/RelNotes/2.3.3.txt @@ -0,0 +1,39 @@ +Git v2.3.3 Release Notes +======================== + +Fixes since v2.3.2 +------------------ + + * A corrupt input to "git diff -M" used cause us to segfault. + + * The borrowed code in kwset API did not follow our usual convention + to use "unsigned char" to store values that range from 0-255. + + * Description given by "grep -h" for its --exclude-standard option + was phrased poorly. + + * Documentaton for "git remote add" mentioned "--tags" and + "--no-tags" and it was not clear that fetch from the remote in + the future will use the default behaviour when neither is given + to override it. + + * "git diff --shortstat --dirstat=changes" showed a dirstat based on + lines that was never asked by the end user in addition to the + dirstat that the user asked for. + + * The interaction between "git submodule update" and the + submodule.*.update configuration was not clearly documented. + + * "git apply" was not very careful about reading from, removing, + updating and creating paths outside the working tree (under + --index/--cached) or the current directory (when used as a + replacement for GNU patch). + + * "git daemon" looked up the hostname even when "%CH" and "%IP" + interpolations are not requested, which was unnecessary. + + * The "interpolated-path" option of "git daemon" inserted any string + client declared on the "host=" capability request without checking. + Sanitize and limit %H and %CH to a saner and a valid DNS name. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.4.txt b/Documentation/RelNotes/2.3.4.txt new file mode 100644 index 0000000..094c7b8 --- /dev/null +++ b/Documentation/RelNotes/2.3.4.txt @@ -0,0 +1,32 @@ +Git v2.3.4 Release Notes +======================== + +Fixes since v2.3.3 +------------------ + + * The 'color.status.unmerged' configuration was not described. + + * "git log --decorate" did not reset colors correctly around the + branch names. + + * "git -C '' subcmd" refused to work in the current directory, unlike + "cd ''" which silently behaves as a no-op. + + * "git imap-send" learned to optionally talk with an IMAP server via + libcURL; because there is no other option when Git is built with + NO_OPENSSL option, use that codepath by default under such + configuration. + + * A workaround for certain build of GPG that triggered false breakage + in a test has been added. + + * "git rebase -i" recently started to include the number of + commits in the insn sheet to be processed, but on a platform + that prepends leading whitespaces to "wc -l" output, the numbers + are shown with extra whitespaces that aren't necessary. + + * We did not parse username followed by literal IPv6 address in SSH + transport URLs, e.g. ssh://user@[2001:db8::1]:22/repo.git + correctly. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.5.txt b/Documentation/RelNotes/2.3.5.txt new file mode 100644 index 0000000..5b309db --- /dev/null +++ b/Documentation/RelNotes/2.3.5.txt @@ -0,0 +1,44 @@ +Git v2.3.5 Release Notes +======================== + +Fixes since v2.3.4 +------------------ + + * The prompt script (in contrib/) did not show the untracked sign + when working in a subdirectory without any untracked files. + + * Even though "git grep --quiet" is run merely to ask for the exit + status, we spawned the pager regardless. Stop doing that. + + * Recommend format-patch and send-email for those who want to submit + patches to this project. + + * An failure early in the "git clone" that started creating the + working tree and repository could have resulted in some directories + and files left without getting cleaned up. + + * "git fetch" that fetches a commit using the allow-tip-sha1-in-want + extension could have failed to fetch all the requested refs. + + * The split-index mode introduced at v2.3.0-rc0~41 was broken in the + codepath to protect us against a broken reimplementation of Git + that writes an invalid index with duplicated index entries, etc. + + * "git prune" used to largely ignore broken refs when deciding which + objects are still being used, which could spread an existing small + damage and make it a larger one. + + * "git tag -h" used to show the "--column" and "--sort" options + that are about listing in a wrong section. + + * The transfer.hiderefs support did not quite work for smart-http + transport. + + * The code that reads from the ctags file in the completion script + (in contrib/) did not spell ${param/pattern/string} substitution + correctly, which happened to work with bash but not with zsh. + + * The explanation on "rebase --preserve-merges", "pull --rebase=preserve", + and "push --force-with-lease" in the documentation was unclear. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index e6d46ed..98fc4cc 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -57,7 +57,8 @@ change, the approach taken by the change, and if relevant how this differs substantially from the prior version, are all good things to have. -Make sure that you have tests for the bug you are fixing. +Make sure that you have tests for the bug you are fixing. See +t/README for guidance. When adding a new feature, make sure that you have new tests to show the feature triggers the new behaviour when it should, and to show the @@ -135,6 +136,11 @@ that is fine, but please mark it as such. (4) Sending your patches. +Learn to use format-patch and send-email if possible. These commands +are optimized for the workflow of sending patches, avoiding many ways +your existing e-mail client that is optimized for "multipart/*" mime +type e-mails to corrupt and render your patches unusable. + People on the Git mailing list need to be able to read and comment on the changes you are submitting. It is important for a developer to be able to "quote" your changes, using standard @@ -175,8 +181,11 @@ message starts, you can put a "From: " line to name that person. You often want to add additional explanation about the patch, other than the commit message itself. Place such "cover letter" -material between the three dash lines and the diffstat. Git-notes -can also be inserted using the `--notes` option. +material between the three-dash line and the diffstat. For +patches requiring multiple iterations of review and discussion, +an explanation of changes between each iteration can be kept in +Git-notes and inserted automatically following the three-dash +line via `git format-patch --notes`. Do not attach the patch as a MIME attachment, compressed or not. Do not let your e-mail client send quoted-printable. Do not let @@ -254,15 +263,15 @@ pretty simple: if you can certify the below: person who certified (a), (b) or (c) and I have not modified it. - (d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. + (d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. then you just add a line saying - Signed-off-by: Random J Developer <random@developer.example.org> + Signed-off-by: Random J Developer <random@developer.example.org> This line can be automatically added by Git if you run the git-commit command with the -s option. @@ -337,7 +346,7 @@ suggests to the contributors: spend their time to improve your patch. Go back to step (2). (4) The list forms consensus that the last round of your patch is - good. Send it to the list and cc the maintainer. + good. Send it to the maintainer and cc the list. (5) A topic branch is created with the patch and is merged to 'next', and cooked further and eventually graduates to 'master'. diff --git a/Documentation/config.txt b/Documentation/config.txt index 51947a9..1a8ddb4 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -14,7 +14,8 @@ the fully qualified variable name of the variable itself is the last dot-separated segment and the section name is everything before the last dot. The variable names are case-insensitive, allow only alphanumeric characters and `-`, and must start with an alphabetic character. Some -variables may appear multiple times. +variables may appear multiple times; we say then that the variable is +multivalued. Syntax ~~~~~~ @@ -25,7 +26,7 @@ blank lines are ignored. The file consists of sections and variables. A section begins with the name of the section in square brackets and continues until the next -section begins. Section names are not case sensitive. Only alphanumeric +section begins. Section names are case-insensitive. Only alphanumeric characters, `-` and `.` are allowed in section names. Each variable must belong to some section, which means that there must be a section header before the first setting of a variable. @@ -40,8 +41,8 @@ in the section header, like in the example below: -------- Subsection names are case sensitive and can contain any characters except -newline (doublequote `"` and backslash have to be escaped as `\"` and `\\`, -respectively). Section headers cannot span multiple +newline (doublequote `"` and backslash can be included by escaping them +as `\"` and `\\`, respectively). Section headers cannot span multiple lines. Variables may belong directly to a section or to a given subsection. You can have `[section]` if you have `[section "subsection"]`, but you don't need to. @@ -53,38 +54,27 @@ restrictions as section names. All the other lines (and the remainder of the line after the section header) are recognized as setting variables, in the form -'name = value'. If there is no equal sign on the line, the entire line -is taken as 'name' and the variable is recognized as boolean "true". +'name = value' (or just 'name', which is a short-hand to say that +the variable is the boolean "true"). The variable names are case-insensitive, allow only alphanumeric characters -and `-`, and must start with an alphabetic character. There can be more -than one value for a given variable; we say then that the variable is -multivalued. - -Leading and trailing whitespace in a variable value is discarded. -Internal whitespace within a variable value is retained verbatim. +and `-`, and must start with an alphabetic character. -The values following the equals sign in variable assign are all either -a string, an integer, or a boolean. Boolean values may be given as yes/no, -1/0, true/false or on/off. Case is not significant in boolean values, when -converting value to the canonical form using '--bool' type specifier; -'git config' will ensure that the output is "true" or "false". +A line that defines a value can be continued to the next line by +ending it with a `\`; the backquote and the end-of-line are +stripped. Leading whitespaces after 'name =', the remainder of the +line after the first comment character '#' or ';', and trailing +whitespaces of the line are discarded unless they are enclosed in +double quotes. Internal whitespaces within the value are retained +verbatim. -String values may be entirely or partially enclosed in double quotes. -You need to enclose variable values in double quotes if you want to -preserve leading or trailing whitespace, or if the variable value contains -comment characters (i.e. it contains '#' or ';'). -Double quote `"` and backslash `\` characters in variable values must -be escaped: use `\"` for `"` and `\\` for `\`. +Inside double quotes, double quote `"` and backslash `\` characters +must be escaped: use `\"` for `"` and `\\` for `\`. The following escape sequences (beside `\"` and `\\`) are recognized: `\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB) and `\b` for backspace (BS). Other char escape sequences (including octal escape sequences) are invalid. -Variable values ending in a `\` are continued on the next line in the -customary UNIX fashion. - -Some variables may require a special value format. Includes ~~~~~~~~ @@ -126,6 +116,61 @@ Example path = foo ; expand "foo" relative to the current file path = ~/foo ; expand "foo" in your $HOME directory + +Values +~~~~~~ + +Values of many variables are treated as a simple string, but there +are variables that take values of specific types and there are rules +as to how to spell them. + +boolean:: + + When a variable is said to take a boolean value, many + synonyms are accepted for 'true' and 'false'; these are all + case-insensitive. + + true;; Boolean true can be spelled as `yes`, `on`, `true`, + or `1`. Also, a variable defined without `= <value>` + is taken as true. + + false;; Boolean false can be spelled as `no`, `off`, + `false`, or `0`. ++ +When converting value to the canonical form using '--bool' type +specifier; 'git config' will ensure that the output is "true" or +"false" (spelled in lowercase). + +integer:: + The value for many variables that specify various sizes can + be suffixed with `k`, `M`,... to mean "scale the number by + 1024", "by 1024x1024", etc. + +color:: + The value for a variables that takes a color is a list of + colors (at most two) and attributes (at most one), separated + by spaces. The colors accepted are `normal`, `black`, + `red`, `green`, `yellow`, `blue`, `magenta`, `cyan` and + `white`; the attributes are `bold`, `dim`, `ul`, `blink` and + `reverse`. The first color given is the foreground; the + second is the background. The position of the attribute, if + any, doesn't matter. Attributes may be turned off + specifically by prefixing them with `no` (e.g., `noreverse`, + `noul`, etc). ++ +Colors (foreground and background) may also be given as numbers between +0 and 255; these use ANSI 256-color mode (but note that not all +terminals may support this). If your terminal supports it, you may also +specify 24-bit RGB values as hex, like `#ff0ab3`. ++ +The attributes are meant to be reset at the beginning of each item +in the colored output, so setting color.decorate.branch to `black` +will paint that branch name in a plain `black`, even if the previous +thing on the same output line (e.g. opening parenthesis before the +list of branch names in `log --decorate` output) is set to be +painted with `bold` or some other attribute. + + Variables ~~~~~~~~~ @@ -204,13 +249,26 @@ advice.*:: -- core.fileMode:: - If false, the executable bit differences between the index and - the working tree are ignored; useful on broken filesystems like FAT. - See linkgit:git-update-index[1]. + Tells Git if the executable bit of files in the working tree + is to be honored. + -The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] -will probe and set core.fileMode false if appropriate when the -repository is created. +Some filesystems lose the executable bit when a file that is +marked as executable is checked out, or checks out an +non-executable file with executable bit on. +linkgit:git-clone[1] or linkgit:git-init[1] probe the filesystem +to see if it handles the executable bit correctly +and this variable is automatically set as necessary. ++ +A repository, however, may be on a filesystem that handles +the filemode correctly, and this variable is set to 'true' +when created, but later may be made accessible from another +environment that loses the filemode (e.g. exporting ext4 via +CIFS mount, visiting a Cygwin created repository with +Git for Windows or Eclipse). +In such a case it may be necessary to set this variable to 'false'. +See linkgit:git-update-index[1]. ++ +The default is true (when core.filemode is not specified in the config file). core.ignorecase:: If true, this option enables various workarounds to enable @@ -233,6 +291,17 @@ core.precomposeunicode:: When false, file names are handled fully transparent by Git, which is backward compatible with older versions of Git. +core.protectHFS:: + If set to true, do not allow checkout of paths that would + be considered equivalent to `.git` on an HFS+ filesystem. + Defaults to `true` on Mac OS, and `false` elsewhere. + +core.protectNTFS:: + If set to true, do not allow checkout of paths that would + cause problems with the NTFS filesystem, e.g. conflict with + 8.3 "short" names. + Defaults to `true` on Windows, and `false` elsewhere. + core.trustctime:: If false, the ctime differences between the index and the working tree are ignored; useful when the inode change time @@ -351,14 +420,19 @@ This is useful for excluding servers inside a firewall from proxy use, while defaulting to a common proxy for external domains. core.ignoreStat:: - If true, commands which modify both the working tree and the index - will mark the updated paths with the "assume unchanged" bit in the - index. These marked files are then assumed to stay unchanged in the - working tree, until you mark them otherwise manually - Git will not - detect the file changes by lstat() calls. This is useful on systems - where those are very slow, such as Microsoft Windows. - See linkgit:git-update-index[1]. - False by default. + If true, Git will avoid using lstat() calls to detect if files have + changed by setting the "assume-unchanged" bit for those tracked files + which it has updated identically in both the index and working tree. ++ +When files are modified outside of Git, the user will need to stage +the modified files explicitly (e.g. see 'Examples' section in +linkgit:git-update-index[1]). +Git will not normally detect changes to those files. ++ +This is useful on systems where lstat() calls are very slow, such as +CIFS/Microsoft Windows. ++ +False by default. core.preferSymlinkRefs:: Instead of the default "symref" format for HEAD @@ -499,7 +573,8 @@ core.bigFileThreshold:: Files larger than this size are stored deflated, without attempting delta compression. Storing large files without delta compression avoids excessive memory usage, at the - slight expense of increased disk usage. + slight expense of increased disk usage. Additionally files + larger than this size are always treated as binary. + Default is 512 MiB on all platforms. This should be reasonable for most projects as source code and other text files can still @@ -653,14 +728,13 @@ core.abbrev:: for abbreviated object names to stay unique for sufficiently long time. -add.ignore-errors:: add.ignoreErrors:: +add.ignore-errors (deprecated):: Tells 'git add' to continue adding files when some files cannot be added due to indexing errors. Equivalent to the '--ignore-errors' - option of linkgit:git-add[1]. Older versions of Git accept only - `add.ignore-errors`, which does not follow the usual naming - convention for configuration variables. Newer versions of Git - honor `add.ignoreErrors` as well. + option of linkgit:git-add[1]. `add.ignore-errors` is deprecated, + as it does not follow the usual naming convention for configuration + variables. alias.*:: Command aliases for the linkgit:git[1] command wrapper - e.g. @@ -817,20 +891,6 @@ color.branch.<slot>:: `remote` (a remote-tracking branch in refs/remotes/), `upstream` (upstream tracking branch), `plain` (other refs). -+ -The value for these configuration variables is a list of colors (at most -two) and attributes (at most one), separated by spaces. The colors -accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`, -`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`, -`blink` and `reverse`. The first color given is the foreground; the -second is the background. The position of the attribute, if any, -doesn't matter. Attributes may be turned off specifically by prefixing -them with `no` (e.g., `noreverse`, `noul`, etc). -+ -Colors (foreground and background) may also be given as numbers between -0 and 255; these use ANSI 256-color mode (but note that not all -terminals may support this). If your terminal supports it, you may also -specify 24-bit RGB values as hex, like `#ff0ab3`. color.diff:: Whether to use ANSI escape sequences to add color to patches. @@ -850,8 +910,7 @@ color.diff.<slot>:: of `plain` (context text), `meta` (metainformation), `frag` (hunk header), 'func' (function in hunk header), `old` (removed lines), `new` (added lines), `commit` (commit headers), or `whitespace` - (highlighting whitespace errors). The values of these variables may be - specified as in color.branch.<slot>. + (highlighting whitespace errors). color.decorate.<slot>:: Use customized color for 'git log --decorate' output. `<slot>` is one @@ -877,15 +936,17 @@ color.grep.<slot>:: `linenumber`;; line number prefix (when using `-n`) `match`;; - matching text + matching text (same as setting `matchContext` and `matchSelected`) +`matchContext`;; + matching text in context lines +`matchSelected`;; + matching text in selected lines `selected`;; non-matching text in selected lines `separator`;; separators between fields on a line (`:`, `-`, and `=`) and between hunks (`--`) -- -+ -The values of these variables may be specified as in color.branch.<slot>. color.interactive:: When set to `always`, always use colors for interactive prompts @@ -898,8 +959,7 @@ color.interactive.<slot>:: Use customized color for 'git add --interactive' and 'git clean --interactive' output. `<slot>` may be `prompt`, `header`, `help` or `error`, for four distinct types of normal output from - interactive commands. The values of these variables may be - specified as in color.branch.<slot>. + interactive commands. color.pager:: A boolean to enable/disable colored output when the pager is in @@ -923,10 +983,10 @@ color.status.<slot>:: `added` or `updated` (files which are added but not committed), `changed` (files which are changed but not added in the index), `untracked` (files which are not tracked by Git), - `branch` (the current branch), or + `branch` (the current branch), `nobranch` (the color the 'no branch' warning is shown in, defaulting - to red). The values of these variables may be specified as in - color.branch.<slot>. + to red), or + `unmerged` (files which have unmerged changes). color.ui:: This variable determines the default value for variables such @@ -1198,7 +1258,7 @@ gc.autopacklimit:: default value is 50. Setting this to 0 disables it. gc.autodetach:: - Make `git gc --auto` return immediately andrun in background + Make `git gc --auto` return immediately and run in background if the system supports it. Default is true. gc.packrefs:: @@ -1345,7 +1405,7 @@ gpg.program:: same command-line interface as GPG, namely, to verify a detached signature, "gpg --verify $file - <$signature" is run, and the program is expected to signal a good signature by exiting with - code 0, and to generate an ascii-armored detached signature, the + code 0, and to generate an ASCII-armored detached signature, the standard input of "gpg -bsau $key" is fed with the contents to be signed, and the program is expected to send the result to its standard output. @@ -1580,7 +1640,7 @@ http.useragent:: Can be overridden by the 'GIT_HTTP_USER_AGENT' environment variable. http.<url>.*:: - Any of the http.* options above can be applied selectively to some urls. + Any of the http.* options above can be applied selectively to some URLs. For a config key to match a URL, each element of the config key is compared to that of the URL, in the following order: + @@ -1619,8 +1679,8 @@ if the URL is `https://user@example.com/foo/bar` a config key match of + All URLs are normalized before attempting any matching (the password part, if embedded in the URL, is always ignored for matching purposes) so that -equivalent urls that are simply spelled differently will match properly. -Environment variable settings always override any matches. The urls that are +equivalent URLs that are simply spelled differently will match properly. +Environment variable settings always override any matches. The URLs that are matched against are those given directly to Git commands. This means any URLs visited as a result of a redirection do not participate in matching. @@ -1706,6 +1766,13 @@ log.mailmap:: If true, makes linkgit:git-log[1], linkgit:git-show[1], and linkgit:git-whatchanged[1] assume `--use-mailmap`. +mailinfo.scissors:: + If true, makes linkgit:git-mailinfo[1] (and therefore + linkgit:git-am[1]) act by default as if the --scissors option + was provided on the command-line. When active, this features + removes everything from the message body before a scissors + line (i.e. consisting mainly of ">8", "8<" and "-"). + mailmap.file:: The location of an augmenting mailmap file. The default mailmap, located in the root of the repository, is loaded @@ -1782,6 +1849,12 @@ mergetool.keepTemporaries:: preserved, otherwise they will be removed after the tool has exited. Defaults to `false`. +mergetool.writeToTemp:: + Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of + conflicting files in the worktree by default. Git will attempt + to use a temporary directory for these files when set `true`. + Defaults to `false`. + mergetool.prompt:: Prompt before each invocation of the merge resolution program. @@ -1842,10 +1915,11 @@ pack.depth:: maximum depth is given on the command line. Defaults to 50. pack.windowMemory:: - The window memory size limit used by linkgit:git-pack-objects[1] - when no limit is given on the command line. The value can be - suffixed with "k", "m", or "g". Defaults to 0, meaning no - limit. + The maximum size of memory that is consumed by each thread + in linkgit:git-pack-objects[1] for pack window memory when + no limit is given on the command line. The value can be + suffixed with "k", "m", or "g". When left unconfigured (or + set explicitly to 0), there will be no limit. pack.compression:: An integer -1..9, indicating the compression level for objects @@ -1919,7 +1993,7 @@ pack.useBitmaps:: true. You should not generally need to turn this off unless you are debugging pack bitmaps. -pack.writebitmaps:: +pack.writebitmaps (deprecated):: This is a deprecated synonym for `repack.writeBitmaps`. pack.writeBitmapHashCache:: @@ -2058,6 +2132,25 @@ receive.autogc:: receiving data from git-push and updating refs. You can stop it by setting this variable to false. +receive.certnonceseed:: + By setting this variable to a string, `git receive-pack` + will accept a `git push --signed` and verifies it by using + a "nonce" protected by HMAC using this string as a secret + key. + +receive.certnonceslop:: + When a `git push --signed` sent a push certificate with a + "nonce" that was issued by a receive-pack serving the same + repository within this many seconds, export the "nonce" + found in the certificate to `GIT_PUSH_CERT_NONCE` to the + hooks (instead of what the receive-pack asked the sending + side to include). This may allow writing checks in + `pre-receive` and `post-receive` a bit easier. Instead of + checking `GIT_PUSH_CERT_NONCE_SLOP` environment variable + that records by how many seconds the nonce is stale to + decide if they want to accept the certificate, they only + can check `GIT_PUSH_CERT_NONCE_STATUS` is `OK`. + receive.fsckObjects:: If it is set to true, git-receive-pack will check all received objects. It will abort in the case of a malformed object or a @@ -2091,6 +2184,13 @@ receive.denyCurrentBranch:: print a warning of such a push to stderr, but allow the push to proceed. If set to false or "ignore", allow such pushes with no message. Defaults to "refuse". ++ +Another option is "updateInstead" which will update the working +directory (must be clean) if pushing into the current branch. This option is +intended for synchronizing working directories when one side is not easily +accessible via interactive ssh (e.g. a live web site, hence the requirement +that the working directory be clean). This mode also comes in handy when +developing inside a VM to test and fix code on different Operating Systems. receive.denyNonFastForwards:: If set to true, git-receive-pack will deny a ref update which is @@ -2230,7 +2330,7 @@ sendemail.smtpencryption:: See linkgit:git-send-email[1] for description. Note that this setting is not subject to the 'identity' mechanism. -sendemail.smtpssl:: +sendemail.smtpssl (deprecated):: Deprecated alias for 'sendemail.smtpencryption = ssl'. sendemail.smtpsslcertpath:: @@ -2265,10 +2365,12 @@ sendemail.smtpserverport:: sendemail.smtpserveroption:: sendemail.smtpuser:: sendemail.thread:: +sendemail.transferencoding:: sendemail.validate:: +sendemail.xmailer:: See linkgit:git-send-email[1] for description. -sendemail.signedoffcc:: +sendemail.signedoffcc (deprecated):: Deprecated alias for 'sendemail.signedoffbycc'. showbranch.default:: @@ -2333,12 +2435,16 @@ status.submodulesummary:: submodule.<name>.path:: submodule.<name>.url:: + The path within this project and URL for a submodule. These + variables are initially populated by 'git submodule init'. See + linkgit:git-submodule[1] and linkgit:gitmodules[5] for + details. + submodule.<name>.update:: - The path within this project, URL, and the updating strategy - for a submodule. These variables are initially populated - by 'git submodule init'; edit them to override the - URL and other values found in the `.gitmodules` file. See - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. + The default update procedure for a submodule. This variable + is populated by `git submodule init` from the + linkgit:gitmodules[5] file. See description of 'update' + command in linkgit:git-submodule[1]. submodule.<name>.branch:: The remote branch name for a submodule, used by `git submodule diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt index 15c7e79..85b0890 100644 --- a/Documentation/diff-format.txt +++ b/Documentation/diff-format.txt @@ -66,7 +66,8 @@ be committed) Status letters C and R are always followed by a score (denoting the percentage of similarity between the source and target of the move or -copy), and are the only ones to be so. +copy). Status letter M may be followed by a score (denoting the +percentage of dissimilarity) for file rewrites. <sha1> is shown as all 0's if a file is new on the filesystem and it is out of sync with the index. diff --git a/Documentation/everyday.txto b/Documentation/everyday.txto new file mode 100644 index 0000000..c5047d8 --- /dev/null +++ b/Documentation/everyday.txto @@ -0,0 +1,9 @@ +Everyday Git With 20 Commands Or So +=================================== + +This document has been moved to linkgit:giteveryday[1]. + +Please let the owners of the referring site know so that they can update the +link you clicked to get here. + +Thanks. diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 9631526..1c74907 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -8,7 +8,7 @@ git-add - Add file contents to the index SYNOPSIS -------- [verse] -'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p] +'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--] [<pathspec>...] diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 9adce37..0d8ba48 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -52,11 +52,23 @@ OPTIONS -c:: --scissors:: Remove everything in body before a scissors line (see - linkgit:git-mailinfo[1]). + linkgit:git-mailinfo[1]). Can be activated by default using + the `mailinfo.scissors` configuration variable. --no-scissors:: Ignore scissors lines (see linkgit:git-mailinfo[1]). +-m:: +--message-id:: + Pass the `-m` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]), + so that the Message-ID header is added to the commit message. + The `am.messageid` configuration variable can be used to specify + the default behaviour. + +--no-message-id:: + Do not add the Message-ID header to the commit message. + `no-message-id` is useful to override `am.messageid`. + -q:: --quiet:: Be quiet. Only print error messages. @@ -83,7 +95,6 @@ default. You can use `--no-utf8` to override this. it is supposed to apply to and we have those blobs available locally. ---ignore-date:: --ignore-space-change:: --ignore-whitespace:: --whitespace=<option>:: diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index f605327..9489664 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -16,7 +16,7 @@ SYNOPSIS [--ignore-space-change | --ignore-whitespace ] [--whitespace=(nowarn|warn|fix|error|error-all)] [--exclude=<path>] [--include=<path>] [--directory=<root>] - [--verbose] [<patch>...] + [--verbose] [--unsafe-paths] [<patch>...] DESCRIPTION ----------- @@ -229,6 +229,16 @@ For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh` can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by running `git apply --directory=modules/git-gui`. +--unsafe-paths:: + By default, a patch that affects outside the working area + (either a Git controlled working tree, or the current working + directory when "git apply" is used as a replacement of GNU + patch) is rejected as a mistake (or a mischief). ++ +When `git apply` is used as a "better GNU patch", the user can pass +the `--unsafe-paths` option to override this safety check. This option +has no effect when `--index` or `--cached` is in use. + Configuration ------------- diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt index afeb86c..0f0c6ff 100644 --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@ -119,7 +119,7 @@ developed and maintained during years or even tens of years by a lot of people. And as there are often many people who depend (sometimes critically) on such software, regressions are a really big problem. -One such software is the linux kernel. And if we look at the linux +One such software is the Linux kernel. And if we look at the Linux kernel, we can see that a lot of time and effort is spent to fight regressions. The release cycle start with a 2 weeks long merge window. Then the first release candidate (rc) version is tagged. And @@ -132,7 +132,7 @@ regressions. And this time is more than 80% of the release cycle time. But this is not the end of the fight yet, as of course it continues after the release. -And then this is what Ingo Molnar (a well known linux kernel +And then this is what Ingo Molnar (a well known Linux kernel developer) says about his use of git bisect: _____________ diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt index ee2e091..788a011 100644 --- a/Documentation/git-check-ignore.txt +++ b/Documentation/git-check-ignore.txt @@ -21,6 +21,9 @@ the exclude mechanism) that decides if the pathname is excluded or included. Later patterns within a file take precedence over earlier ones. +By default, tracked files are not shown at all since they are not +subject to exclude rules; but see `--no-index'. + OPTIONS ------- -q, --quiet:: diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index 1c03c79..1147c71 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -131,7 +131,8 @@ effect to your index in a row. --keep-redundant-commits:: If a commit being cherry picked duplicates a commit already in the current history, it will become empty. By default these - redundant commits are ignored. This option overrides that behavior and + redundant commits cause `cherry-pick` to stop so the user can + examine the commit. This option overrides that behavior and creates an empty commit object. Implies `--allow-empty`. --strategy=<strategy>:: diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index 8997922..641681f 100644 --- a/Documentation/git-clean.txt +++ b/Documentation/git-clean.txt @@ -34,8 +34,12 @@ OPTIONS -f:: --force:: If the Git configuration variable clean.requireForce is not set - to false, 'git clean' will refuse to run unless given -f, -n or - -i. + to false, 'git clean' will refuse to delete files or directories + unless given -f, -n or -i. Git will refuse to delete directories + with .git sub directory or file unless a second -f + is given. This affects also git submodules where the storage area + of the removed submodule under .git/modules/ is not removed until + -f is given twice. -i:: --interactive:: @@ -98,7 +102,7 @@ clean:: filter by pattern:: This shows the files and directories to be deleted and issues an - "Input ignore patterns>>" prompt. You can input space-seperated + "Input ignore patterns>>" prompt. You can input space-separated patterns to exclude files and directories from deletion. E.g. "*.c *.h" will excludes files end with ".c" and ".h" from deletion. When you are satisfied with the filtered result, press diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 0363d00..f1f2a3f 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -12,7 +12,7 @@ SYNOPSIS 'git clone' [--template=<template_directory>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] - [--separate-git-dir <git dir>] + [--dissociate] [--separate-git-dir <git dir>] [--depth <depth>] [--[no-]single-branch] [--recursive | --recurse-submodules] [--] <repository> [<directory>] @@ -98,7 +98,14 @@ objects from the source repository into a pack in the cloned repository. require fewer objects to be copied from the repository being cloned, reducing network and local storage costs. + -*NOTE*: see the NOTE for the `--shared` option. +*NOTE*: see the NOTE for the `--shared` option, and also the +`--dissociate` option. + +--dissociate:: + Borrow the objects from reference repositories specified + with the `--reference` options only to reduce network + transfer and stop borrowing from them after a clone is made + by making necessary local copies of borrowed objects. --quiet:: -q:: diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 0bbc8f5..1e74b75 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -250,9 +250,10 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].) -o:: --only:: - Make a commit only from the paths specified on the + Make a commit by taking the updated working tree contents + of the paths specified on the command line, disregarding any contents that have been - staged so far. This is the default mode of operation of + staged for other paths. This is the default mode of operation of 'git commit' if any paths are given on the command line, in which case this option can be omitted. If this option is specified together with '--amend', then diff --git a/Documentation/git-credential-cache--daemon.txt b/Documentation/git-credential-cache--daemon.txt index d15db42..7051c6b 100644 --- a/Documentation/git-credential-cache--daemon.txt +++ b/Documentation/git-credential-cache--daemon.txt @@ -8,7 +8,7 @@ git-credential-cache--daemon - Temporarily store user credentials in memory SYNOPSIS -------- [verse] -git credential-cache--daemon <socket> +git credential-cache--daemon [--debug] <socket> DESCRIPTION ----------- @@ -21,6 +21,10 @@ for `git-credential-cache` clients. Clients may store and retrieve credentials. Each credential is held for a timeout specified by the client; once no credentials are held, the daemon exits. +If the `--debug` option is specified, the daemon does not close its +stderr stream, and may output extra diagnostics to it even after it has +begun listening for clients. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 260f39f..00a0679 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -219,7 +219,7 @@ Problems related to tags: * Multiple tags on the same revision are not imported. If you suspect that any of these issues may apply to the repository you -want to imort, consider using cvs2git: +want to import, consider using cvs2git: * cvs2git (part of cvs2svn), `http://subversion.apache.org/` diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt index 472f5cb..4961f1a 100644 --- a/Documentation/git-cvsserver.txt +++ b/Documentation/git-cvsserver.txt @@ -110,7 +110,7 @@ to allow writes to, for example: authdb = /etc/cvsserver/passwd ------ -The format of these files is username followed by the crypted password, +The format of these files is username followed by the encrypted password, for example: ------ diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt index 11887e6..333cf6f 100644 --- a/Documentation/git-difftool.txt +++ b/Documentation/git-difftool.txt @@ -91,6 +91,15 @@ instead. `--no-symlinks` is the default on Windows. the default diff tool will be read from the configured `diff.guitool` variable instead of `diff.tool`. +--[no-]trust-exit-code:: + 'git-difftool' invokes a diff tool individually on each file. + Errors reported by the diff tool are ignored by default. + Use `--trust-exit-code` to make 'git-difftool' exit when an + invoked diff tool returns a non-zero exit code. ++ +'git-difftool' will forward the exit code of the invoked tool when +'--trust-exit-code' is used. + See linkgit:git-diff[1] for the full list of supported options. CONFIG VARIABLES @@ -116,6 +125,11 @@ See the `--tool=<tool>` option above for more details. difftool.prompt:: Prompt before each invocation of the diff tool. +difftool.trustExitCode:: + Exit difftool if the invoked diff tool returns a non-zero exit status. ++ +See the `--trust-exit-code` option above for more details. + SEE ALSO -------- linkgit:git-diff[1]:: diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt index 221506b..929e496 100644 --- a/Documentation/git-fast-export.txt +++ b/Documentation/git-fast-export.txt @@ -105,6 +105,11 @@ marks the same across runs. in the commit (as opposed to just listing the files which are different from the commit's first parent). +--anonymize:: + Anonymize the contents of the repository while still retaining + the shape of the history and stored tree. See the section on + `ANONYMIZING` below. + --refspec:: Apply the specified refspec to each ref exported. Multiple of them can be specified. @@ -141,6 +146,62 @@ referenced by that revision range contains the string 'refs/heads/master'. +ANONYMIZING +----------- + +If the `--anonymize` option is given, git will attempt to remove all +identifying information from the repository while still retaining enough +of the original tree and history patterns to reproduce some bugs. The +goal is that a git bug which is found on a private repository will +persist in the anonymized repository, and the latter can be shared with +git developers to help solve the bug. + +With this option, git will replace all refnames, paths, blob contents, +commit and tag messages, names, and email addresses in the output with +anonymized data. Two instances of the same string will be replaced +equivalently (e.g., two commits with the same author will have the same +anonymized author in the output, but bear no resemblance to the original +author string). The relationship between commits, branches, and tags is +retained, as well as the commit timestamps (but the commit messages and +refnames bear no resemblance to the originals). The relative makeup of +the tree is retained (e.g., if you have a root tree with 10 files and 3 +trees, so will the output), but their names and the contents of the +files will be replaced. + +If you think you have found a git bug, you can start by exporting an +anonymized stream of the whole repository: + +--------------------------------------------------- +$ git fast-export --anonymize --all >anon-stream +--------------------------------------------------- + +Then confirm that the bug persists in a repository created from that +stream (many bugs will not, as they really do depend on the exact +repository contents): + +--------------------------------------------------- +$ git init anon-repo +$ cd anon-repo +$ git fast-import <../anon-stream +$ ... test your bug ... +--------------------------------------------------- + +If the anonymized repository shows the bug, it may be worth sharing +`anon-stream` along with a regular bug report. Note that the anonymized +stream compresses very well, so gzipping it is encouraged. If you want +to examine the stream to see that it does not contain any private data, +you can peruse it directly before sending. You may also want to try: + +--------------------------------------------------- +$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less +--------------------------------------------------- + +which shows all of the unique lines (with numbers converted to "X", to +collapse "User 0", "User 1", etc into "User X"). This produces a much +smaller output, and it is usually easy to quickly confirm that there is +no private data in the stream. + + Limitations ----------- @@ -148,6 +209,10 @@ Since 'git fast-import' cannot tag trees, you will not be able to export the linux.git repository completely, as it contains a tag referencing a tree instead of a commit. +SEE ALSO +-------- +linkgit:git-fast-import[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 377eeaa..690fed3 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -507,10 +507,6 @@ omitted when creating a new branch, the first `merge` commit will be the first ancestor of the current commit, and the branch will start out with no files. An unlimited number of `merge` commands per commit are permitted by fast-import, thereby establishing an n-way merge. -However Git's other tools never create commits with more than 15 -additional ancestors (forming a 16-way merge). For this reason -it is suggested that frontends do not use more than 15 `merge` -commands per commit; 16, if starting a new, empty branch. Here `<commit-ish>` is any of the commit specification expressions also accepted by `from` (see above). @@ -1441,6 +1437,10 @@ operator can use this facility to peek at the objects and refs from an import in progress, at the cost of some added running time and worse compression. +SEE ALSO +-------- +linkgit:git-fast-export[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 09535f2..73fd9e8 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -451,8 +451,8 @@ characteristics: * By default The BFG takes full advantage of multi-core machines, cleansing commit file-trees in parallel. git-filter-branch cleans - commits sequentially (ie in a single-threaded manner), though it - _is_ possible to write filters that include their own parallellism, + commits sequentially (i.e. in a single-threaded manner), though it + _is_ possible to write filters that include their own parallelism, in the scripts executed against each commit. * The http://rtyley.github.io/bfg-repo-cleaner/#examples[command options] diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index 875d283..5d1e4c8 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -9,7 +9,7 @@ git-imap-send - Send a collection of patches from stdin to an IMAP folder SYNOPSIS -------- [verse] -'git imap-send' +'git imap-send' [-v] [-q] [--[no-]curl] DESCRIPTION @@ -26,6 +26,28 @@ Typical usage is something like: git format-patch --signoff --stdout --attach origin | git imap-send +OPTIONS +------- + +-v:: +--verbose:: + Be verbose. + +-q:: +--quiet:: + Be quiet. + +--curl:: + Use libcurl to communicate with the IMAP server, unless tunneling + into it. Ignored if Git was built without the USE_CURL_FOR_IMAP_SEND + option set. + +--no-curl:: + Talk to the IMAP server using git's own IMAP routines instead of + using libcurl. Ignored if Git was built with the NO_OPENSSL option + set. + + CONFIGURATION ------------- @@ -38,18 +60,17 @@ Variables imap.folder:: The folder to drop the mails into, which is typically the Drafts folder. For example: "INBOX.Drafts", "INBOX/Drafts" or - "[Gmail]/Drafts". Required to use imap-send. + "[Gmail]/Drafts". Required. imap.tunnel:: Command used to setup a tunnel to the IMAP server through which commands will be piped instead of using a direct network connection - to the server. Required when imap.host is not set to use imap-send. + to the server. Required when imap.host is not set. imap.host:: A URL identifying the server. Use a `imap://` prefix for non-secure connections and a `imaps://` prefix for secure connections. - Ignored when imap.tunnel is set, but required to use imap-send - otherwise. + Ignored when imap.tunnel is set, but required otherwise. imap.user:: The username to use when logging in to the server. @@ -76,7 +97,10 @@ imap.preformattedHTML:: imap.authMethod:: Specify authenticate method for authentication with IMAP server. - Current supported method is 'CRAM-MD5' only. + If Git was built with the NO_CURL option, or if your curl version is older + than 7.34.0, or if you're running git-imap-send with the `--no-curl` + option, the only supported method is 'CRAM-MD5'. If this is not set + then 'git imap-send' uses the basic IMAP plaintext LOGIN command. Examples ~~~~~~~~ @@ -97,7 +121,7 @@ Using direct mode: host = imap://imap.example.com user = bob pass = p4ssw0rd -.......................... +......................... Using direct mode with SSL: @@ -109,7 +133,7 @@ Using direct mode with SSL: pass = p4ssw0rd port = 123 sslverify = false -.......................... +......................... EXAMPLE diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index afd721e..369f889 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -43,7 +43,7 @@ OPTIONS -q:: --quiet:: -Only print error and warning messages, all other output will be suppressed. +Only print error and warning messages; all other output will be suppressed. --bare:: @@ -57,12 +57,12 @@ DIRECTORY" section below.) --separate-git-dir=<git dir>:: -Instead of initializing the repository where it is supposed to be, -place a filesytem-agnostic Git symbolic link there, pointing to the -specified path, and initialize a Git repository at the path. The -result is Git repository can be separated from working tree. If this -is reinitialization, the repository will be moved to the specified -path. +Instead of initializing the repository as a directory to either `$GIT_DIR` or +`./.git/`, create a text file there containing the path to the actual +repository. This file acts as filesystem-agnostic Git symbolic link to the +repository. ++ +If this is reinitialization, the repository will be moved to the specified path. --shared[=(false|true|umask|group|all|world|everybody|0xxx)]:: @@ -72,60 +72,65 @@ repository. When specified, the config variable "core.sharedRepository" is set so that files and directories under `$GIT_DIR` are created with the requested permissions. When not specified, Git will use permissions reported by umask(2). - ++ The option can have the following values, defaulting to 'group' if no value is given: ++ +-- +'umask' (or 'false'):: - - 'umask' (or 'false'): Use permissions reported by umask(2). The default, - when `--shared` is not specified. +Use permissions reported by umask(2). The default, when `--shared` is not +specified. - - 'group' (or 'true'): Make the repository group-writable, (and g+sx, since - the git group may be not the primary group of all users). - This is used to loosen the permissions of an otherwise safe umask(2) value. - Note that the umask still applies to the other permission bits (e.g. if - umask is '0022', using 'group' will not remove read privileges from other - (non-group) users). See '0xxx' for how to exactly specify the repository - permissions. +'group' (or 'true'):: - - 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository - readable by all users. +Make the repository group-writable, (and g+sx, since the git group may be not +the primary group of all users). This is used to loosen the permissions of an +otherwise safe umask(2) value. Note that the umask still applies to the other +permission bits (e.g. if umask is '0022', using 'group' will not remove read +privileges from other (non-group) users). See '0xxx' for how to exactly specify +the repository permissions. - - '0xxx': '0xxx' is an octal number and each file will have mode '0xxx'. - '0xxx' will override users' umask(2) value (and not only loosen permissions - as 'group' and 'all' does). '0640' will create a repository which is - group-readable, but not group-writable or accessible to others. '0660' will - create a repo that is readable and writable to the current user and group, - but inaccessible to others. +'all' (or 'world' or 'everybody'):: -By default, the configuration flag receive.denyNonFastForwards is enabled +Same as 'group', but make the repository readable by all users. + +'0xxx':: + +'0xxx' is an octal number and each file will have mode '0xxx'. '0xxx' will +override users' umask(2) value (and not only loosen permissions as 'group' and +'all' does). '0640' will create a repository which is group-readable, but not +group-writable or accessible to others. '0660' will create a repo that is +readable and writable to the current user and group, but inaccessible to others. +-- + +By default, the configuration flag `receive.denyNonFastForwards` is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. -If you name a (possibly non-existent) directory at the end of the command -line, the command is run inside the directory (possibly after creating it). +If you provide a 'directory', the command is run inside it. If this directory +does not exist, it will be created. -- - TEMPLATE DIRECTORY ------------------ The template directory contains files and directories that will be copied to the `$GIT_DIR` after it is created. -The template directory used will (in order): +The template directory will be one of the following (in order): - - The argument given with the `--template` option. + - the argument given with the `--template` option; - - The contents of the `$GIT_TEMPLATE_DIR` environment variable. + - the contents of the `$GIT_TEMPLATE_DIR` environment variable; - - The `init.templatedir` configuration variable. + - the `init.templatedir` configuration variable; or - - The default template directory: `/usr/share/git-core/templates`. + - the default template directory: `/usr/share/git-core/templates`. -The default template directory includes some directory structure, some -suggested "exclude patterns", and copies of sample "hook" files. -The suggested patterns and hook files are all modifiable and extensible. +The default template directory includes some directory structure, suggested +"exclude patterns" (see linkgit:gitignore[5]), and sample hook files (see linkgit:githooks[5]). EXAMPLES -------- @@ -136,10 +141,12 @@ Start a new Git repository for an existing code base:: $ cd /path/to/my/codebase $ git init <1> $ git add . <2> +$ git commit <3> ---------------- + -<1> prepare /path/to/my/codebase/.git directory -<2> add all existing file to the index +<1> Create a /path/to/my/codebase/.git directory. +<2> Add all existing files to the index. +<3> Record the pristine state as the first commit in the history. GIT --- diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt new file mode 100644 index 0000000..d6d9231 --- /dev/null +++ b/Documentation/git-interpret-trailers.txt @@ -0,0 +1,314 @@ +git-interpret-trailers(1) +========================= + +NAME +---- +git-interpret-trailers - help add structured information into commit messages + +SYNOPSIS +-------- +[verse] +'git interpret-trailers' [--trim-empty] [(--trailer <token>[(=|:)<value>])...] [<file>...] + +DESCRIPTION +----------- +Help adding 'trailers' lines, that look similar to RFC 822 e-mail +headers, at the end of the otherwise free-form part of a commit +message. + +This command reads some patches or commit messages from either the +<file> arguments or the standard input if no <file> is specified. Then +this command applies the arguments passed using the `--trailer` +option, if any, to the commit message part of each input file. The +result is emitted on the standard output. + +Some configuration variables control the way the `--trailer` arguments +are applied to each commit message and the way any existing trailer in +the commit message is changed. They also make it possible to +automatically add some trailers. + +By default, a '<token>=<value>' or '<token>:<value>' argument given +using `--trailer` will be appended after the existing trailers only if +the last trailer has a different (<token>, <value>) pair (or if there +is no existing trailer). The <token> and <value> parts will be trimmed +to remove starting and trailing whitespace, and the resulting trimmed +<token> and <value> will appear in the message like this: + +------------------------------------------------ +token: value +------------------------------------------------ + +This means that the trimmed <token> and <value> will be separated by +`': '` (one colon followed by one space). + +By default the new trailer will appear at the end of all the existing +trailers. If there is no existing trailer, the new trailer will appear +after the commit message part of the output, and, if there is no line +with only spaces at the end of the commit message part, one blank line +will be added before the new trailer. + +Existing trailers are extracted from the input message by looking for +a group of one or more lines that contain a colon (by default), where +the group is preceded by one or more empty (or whitespace-only) lines. +The group must either be at the end of the message or be the last +non-whitespace lines before a line that starts with '---'. Such three +minus signs start the patch part of the message. + +When reading trailers, there can be whitespaces before and after the +token, the separator and the value. There can also be whitespaces +inside the token and the value. + +Note that 'trailers' do not follow and are not intended to follow many +rules for RFC 822 headers. For example they do not follow the line +folding rules, the encoding rules and probably many other rules. + +OPTIONS +------- +--trim-empty:: + If the <value> part of any trailer contains only whitespace, + the whole trailer will be removed from the resulting message. + This apply to existing trailers as well as new trailers. + +--trailer <token>[(=|:)<value>]:: + Specify a (<token>, <value>) pair that should be applied as a + trailer to the input messages. See the description of this + command. + +CONFIGURATION VARIABLES +----------------------- + +trailer.separators:: + This option tells which characters are recognized as trailer + separators. By default only ':' is recognized as a trailer + separator, except that '=' is always accepted on the command + line for compatibility with other git commands. ++ +The first character given by this option will be the default character +used when another separator is not specified in the config for this +trailer. ++ +For example, if the value for this option is "%=$", then only lines +using the format '<token><sep><value>' with <sep> containing '%', '=' +or '$' and then spaces will be considered trailers. And '%' will be +the default separator used, so by default trailers will appear like: +'<token>% <value>' (one percent sign and one space will appear between +the token and the value). + +trailer.where:: + This option tells where a new trailer will be added. ++ +This can be `end`, which is the default, `start`, `after` or `before`. ++ +If it is `end`, then each new trailer will appear at the end of the +existing trailers. ++ +If it is `start`, then each new trailer will appear at the start, +instead of the end, of the existing trailers. ++ +If it is `after`, then each new trailer will appear just after the +last trailer with the same <token>. ++ +If it is `before`, then each new trailer will appear just before the +first trailer with the same <token>. + +trailer.ifexists:: + This option makes it possible to choose what action will be + performed when there is already at least one trailer with the + same <token> in the message. ++ +The valid values for this option are: `addIfDifferentNeighbor` (this +is the default), `addIfDifferent`, `add`, `overwrite` or `doNothing`. ++ +With `addIfDifferentNeighbor`, a new trailer will be added only if no +trailer with the same (<token>, <value>) pair is above or below the line +where the new trailer will be added. ++ +With `addIfDifferent`, a new trailer will be added only if no trailer +with the same (<token>, <value>) pair is already in the message. ++ +With `add`, a new trailer will be added, even if some trailers with +the same (<token>, <value>) pair are already in the message. ++ +With `replace`, an existing trailer with the same <token> will be +deleted and the new trailer will be added. The deleted trailer will be +the closest one (with the same <token>) to the place where the new one +will be added. ++ +With `doNothing`, nothing will be done; that is no new trailer will be +added if there is already one with the same <token> in the message. + +trailer.ifmissing:: + This option makes it possible to choose what action will be + performed when there is not yet any trailer with the same + <token> in the message. ++ +The valid values for this option are: `add` (this is the default) and +`doNothing`. ++ +With `add`, a new trailer will be added. ++ +With `doNothing`, nothing will be done. + +trailer.<token>.key:: + This `key` will be used instead of <token> in the trailer. At + the end of this key, a separator can appear and then some + space characters. By default the only valid separator is ':', + but this can be changed using the `trailer.separators` config + variable. ++ +If there is a separator, then the key will be used instead of both the +<token> and the default separator when adding the trailer. + +trailer.<token>.where:: + This option takes the same values as the 'trailer.where' + configuration variable and it overrides what is specified by + that option for trailers with the specified <token>. + +trailer.<token>.ifexist:: + This option takes the same values as the 'trailer.ifexist' + configuration variable and it overrides what is specified by + that option for trailers with the specified <token>. + +trailer.<token>.ifmissing:: + This option takes the same values as the 'trailer.ifmissing' + configuration variable and it overrides what is specified by + that option for trailers with the specified <token>. + +trailer.<token>.command:: + This option can be used to specify a shell command that will + be called to automatically add or modify a trailer with the + specified <token>. ++ +When this option is specified, the behavior is as if a special +'<token>=<value>' argument were added at the beginning of the command +line, where <value> is taken to be the standard output of the +specified command with any leading and trailing whitespace trimmed +off. ++ +If the command contains the `$ARG` string, this string will be +replaced with the <value> part of an existing trailer with the same +<token>, if any, before the command is launched. ++ +If some '<token>=<value>' arguments are also passed on the command +line, when a 'trailer.<token>.command' is configured, the command will +also be executed for each of these arguments. And the <value> part of +these arguments, if any, will be used to replace the `$ARG` string in +the command. + +EXAMPLES +-------- + +* Configure a 'sign' trailer with a 'Signed-off-by' key, and then + add two of these trailers to a message: ++ +------------ +$ git config trailer.sign.key "Signed-off-by" +$ cat msg.txt +subject + +message +$ cat msg.txt | git interpret-trailers --trailer 'sign: Alice <alice@example.com>' --trailer 'sign: Bob <bob@example.com>' +subject + +message + +Signed-off-by: Alice <alice@example.com> +Signed-off-by: Bob <bob@example.com> +------------ + +* Extract the last commit as a patch, and add a 'Cc' and a + 'Reviewed-by' trailer to it: ++ +------------ +$ git format-patch -1 +0001-foo.patch +$ git interpret-trailers --trailer 'Cc: Alice <alice@example.com>' --trailer 'Reviewed-by: Bob <bob@example.com>' 0001-foo.patch >0001-bar.patch +------------ + +* Configure a 'sign' trailer with a command to automatically add a + 'Signed-off-by: ' with the author information only if there is no + 'Signed-off-by: ' already, and show how it works: ++ +------------ +$ git config trailer.sign.key "Signed-off-by: " +$ git config trailer.sign.ifmissing add +$ git config trailer.sign.ifexists doNothing +$ git config trailer.sign.command 'echo "$(git config user.name) <$(git config user.email)>"' +$ git interpret-trailers <<EOF +> EOF + +Signed-off-by: Bob <bob@example.com> +$ git interpret-trailers <<EOF +> Signed-off-by: Alice <alice@example.com> +> EOF + +Signed-off-by: Alice <alice@example.com> +------------ + +* Configure a 'fix' trailer with a key that contains a '#' and no + space after this character, and show how it works: ++ +------------ +$ git config trailer.separators ":#" +$ git config trailer.fix.key "Fix #" +$ echo "subject" | git interpret-trailers --trailer fix=42 +subject + +Fix #42 +------------ + +* Configure a 'see' trailer with a command to show the subject of a + commit that is related, and show how it works: ++ +------------ +$ git config trailer.see.key "See-also: " +$ git config trailer.see.ifExists "replace" +$ git config trailer.see.ifMissing "doNothing" +$ git config trailer.see.command "git log -1 --oneline --format=\"%h (%s)\" --abbrev-commit --abbrev=14 \$ARG" +$ git interpret-trailers <<EOF +> subject +> +> message +> +> see: HEAD~2 +> EOF +subject + +message + +See-also: fe3187489d69c4 (subject of related commit) +------------ + +* Configure a commit template with some trailers with empty values + (using sed to show and keep the trailing spaces at the end of the + trailers), then configure a commit-msg hook that uses + 'git interpret-trailers' to remove trailers with empty values and + to add a 'git-version' trailer: ++ +------------ +$ sed -e 's/ Z$/ /' >commit_template.txt <<EOF +> ***subject*** +> +> ***message*** +> +> Fixes: Z +> Cc: Z +> Reviewed-by: Z +> Signed-off-by: Z +> EOF +$ git config commit.template commit_template.txt +$ cat >.git/hooks/commit-msg <<EOF +> #!/bin/sh +> git interpret-trailers --trim-empty --trailer "git-version: \$(git describe)" "\$1" > "\$1.new" +> mv "\$1.new" "\$1" +> EOF +$ chmod +x .git/hooks/commit-msg +------------ + +SEE ALSO +-------- +linkgit:git-commit[1], linkgit:git-format-patch[1], linkgit:git-config[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt index 164a3c6..0947084 100644 --- a/Documentation/git-mailinfo.txt +++ b/Documentation/git-mailinfo.txt @@ -66,6 +66,11 @@ conversion, even with this flag. -n:: Disable all charset re-coding of the metadata. +-m:: +--message-id:: + Copy the Message-ID header at the end of the commit message. This + is useful in order to associate commits with mailing list discussions. + --scissors:: Remove everything in body before a scissors line. A line that mainly consists of scissors (either ">8" or "8<") and perforation diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index 310f0a5..851518d 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -9,10 +9,10 @@ SYNOPSIS -------- [verse] 'git notes' [list [<object>]] -'git notes' add [-f] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] +'git notes' add [-f] [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] 'git notes' copy [-f] ( --stdin | <from-object> <to-object> ) -'git notes' append [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] -'git notes' edit [<object>] +'git notes' append [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] +'git notes' edit [--allow-empty] [<object>] 'git notes' show [<object>] 'git notes' merge [-v | -q] [-s <strategy> ] <notes-ref> 'git notes' merge --commit [-v | -q] @@ -155,6 +155,10 @@ OPTIONS Like '-C', but with '-c' the editor is invoked, so that the user can further edit the note message. +--allow-empty:: + Allow an empty note object to be stored. The default behavior is + to automatically remove empty notes. + --ref <ref>:: Manipulate the notes tree in <ref>. This overrides 'GIT_NOTES_REF' and the "core.notesRef" configuration. The ref @@ -287,7 +291,7 @@ arbitrary files using 'git hash-object': ------------ $ cc *.c $ blob=$(git hash-object -w a.out) -$ git notes --ref=built add -C "$blob" HEAD +$ git notes --ref=built add --allow-empty -C "$blob" HEAD ------------ (You cannot simply use `git notes --ref=built add -F a.out HEAD` diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index d2d8f47..c2f76fb 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -13,7 +13,7 @@ SYNOPSIS [--no-reuse-delta] [--delta-base-offset] [--non-empty] [--local] [--incremental] [--window=<n>] [--depth=<n>] [--revs [--unpacked | --all]] [--stdout | base-name] - [--keep-true-parents] < object-list + [--shallow] [--keep-true-parents] < object-list DESCRIPTION @@ -190,6 +190,11 @@ required objects and is thus unusable by Git without making it self-contained. Use `git index-pack --fix-thin` (see linkgit:git-index-pack[1]) to restore the self-contained property. +--shallow:: + Optimize a pack that will be provided to a client with a shallow + repository. This option, combined with \--thin, can result in a + smaller pack at the cost of speed. + --delta-base-offset:: A packed archive can express the base object of a delta as either a 20-byte object name or as an offset in the diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt index 6738055..9fed59a 100644 --- a/Documentation/git-prune-packed.txt +++ b/Documentation/git-prune-packed.txt @@ -1,5 +1,5 @@ git-prune-packed(1) -===================== +=================== NAME ---- diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index 200eb22..4064452 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -111,9 +111,8 @@ include::merge-options.txt[] was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes. + -When preserve, also rebase the current branch on top of the upstream -branch, but pass `--preserve-merges` along to `git rebase` so that -locally created merge commits will not be flattened. +When set to preserve, rebase with the `--preserve-merges` option passed +to `git rebase` so that locally created merge commits will not be flattened. + When false, merge the current branch into the upstream branch. + diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index c0d7403..3593774 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -10,7 +10,8 @@ SYNOPSIS -------- [verse] 'git push' [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>] - [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream] + [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] + [-u | --set-upstream] [--signed] [--force-with-lease[=<refname>[:<expect>]]] [--no-verify] [<repository> [<refspec>...]] @@ -129,6 +130,12 @@ already exists on the remote side. from the remote but are pointing at commit-ish that are reachable from the refs being pushed. +--signed:: + GPG-sign the push request to update refs on the receiving + side, to allow it to be checked by the hooks and/or be + logged. See linkgit:git-receive-pack[1] for the details + on the receiving end. + --receive-pack=<git-receive-pack>:: --exec=<git-receive-pack>:: Path to the 'git-receive-pack' program on the remote @@ -142,9 +149,8 @@ already exists on the remote side. Usually, "git push" refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. + -This option bypasses the check, but instead requires that the -current value of the ref to be the expected value. "git push" -fails otherwise. +This option overrides this restriction if the current value of the +remote ref is the expected value. "git push" fails otherwise. + Imagine that you have to rebase what you have already published. You will have to bypass the "must fast-forward" rule in order to @@ -156,15 +162,14 @@ commit, and blindly pushing with `--force` will lose her work. This option allows you to say that you expect the history you are updating is what you rebased and want to replace. If the remote ref still points at the commit you specified, you can be sure that no -other people did anything to the ref (it is like taking a "lease" on -the ref without explicitly locking it, and you update the ref while -making sure that your earlier "lease" is still valid). +other people did anything to the ref. It is like taking a "lease" on +the ref without explicitly locking it, and the remote ref is updated +only if the "lease" is still valid. + `--force-with-lease` alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have -for them, unless specified with a `--force-with-lease=<refname>:<expect>` -option that explicitly states what the expected value is. +for them. + `--force-with-lease=<refname>`, without specifying the expected value, will protect the named ref (alone), if it is going to be updated, by @@ -207,22 +212,8 @@ origin +master` to force a push to the `master` branch). See the `<refspec>...` section above for details. --repo=<repository>:: - This option is only relevant if no <repository> argument is - passed in the invocation. In this case, 'git push' derives the - remote name from the current branch: If it tracks a remote - branch, then that remote repository is pushed to. Otherwise, - the name "origin" is used. For this latter case, this option - can be used to override the name "origin". In other words, - the difference between these two commands -+ --------------------------- -git push public #1 -git push --repo=public #2 --------------------------- -+ -is that #1 always pushes to "public" whereas #2 pushes to "public" -only if the current branch does not track a remote branch. This is -useful if you write an alias or script around 'git push'. + This option is equivalent to the <repository> argument. If both + are specified, the command-line argument takes precedence. -u:: --set-upstream:: diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt index a356196..d64388c 100644 --- a/Documentation/git-quiltimport.txt +++ b/Documentation/git-quiltimport.txt @@ -1,5 +1,5 @@ git-quiltimport(1) -================ +================== NAME ---- diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 4138554..c8ab48d 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -21,15 +21,17 @@ If <branch> is specified, 'git rebase' will perform an automatic it remains on the current branch. If <upstream> is not specified, the upstream configured in -branch.<name>.remote and branch.<name>.merge options will be used; see -linkgit:git-config[1] for details. If you are currently not on any -branch or if the current branch does not have a configured upstream, -the rebase will abort. +branch.<name>.remote and branch.<name>.merge options will be used (see +linkgit:git-config[1] for details) and the `--fork-point` option is +assumed. If you are currently not on any branch or if the current +branch does not have a configured upstream, the rebase will abort. All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area. This is the same set -of commits that would be shown by `git log <upstream>..HEAD` (or -`git log HEAD`, if --root is specified). +of commits that would be shown by `git log <upstream>..HEAD`; or by +`git log 'fork_point'..HEAD`, if `--fork-point` is active (see the +description on `--fork-point` below); or by `git log HEAD`, if the +`--root` option is specified. The current branch is reset to <upstream>, or <newbase> if the --onto option was supplied. This has the exact same effect as @@ -327,13 +329,18 @@ link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details) --fork-point:: --no-fork-point:: - Use 'git merge-base --fork-point' to find a better common ancestor - between `upstream` and `branch` when calculating which commits have - have been introduced by `branch` (see linkgit:git-merge-base[1]). + Use reflog to find a better common ancestor between <upstream> + and <branch> when calculating which commits have been + introduced by <branch>. + -If no non-option arguments are given on the command line, then the default is -`--fork-point @{u}` otherwise the `upstream` argument is interpreted literally -unless the `--fork-point` option is specified. +When --fork-point is active, 'fork_point' will be used instead of +<upstream> to calculate the set of commits to rebase, where +'fork_point' is the result of `git merge-base --fork-point <upstream> +<branch>` command (see linkgit:git-merge-base[1]). If 'fork_point' +ends up being empty, the <upstream> will be used as a fallback. ++ +If either <upstream> or --root is given on the command line, then the +default is `--no-fork-point`, otherwise the default is `--fork-point`. --ignore-whitespace:: --whitespace=<option>:: @@ -355,7 +362,9 @@ unless the `--fork-point` option is specified. -p:: --preserve-merges:: - Instead of ignoring merges, try to recreate them. + Recreate merge commits instead of flattening the history by replaying + commits a merge commit introduces. Merge conflict resolutions or manual + amendments to merge commits are not preserved. + This uses the `--interactive` machinery internally, but combining it with the `--interactive` option explicitly is generally not a good diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt index b1f7dc6..9016960 100644 --- a/Documentation/git-receive-pack.txt +++ b/Documentation/git-receive-pack.txt @@ -53,6 +53,56 @@ the update. Refs to be created will have sha1-old equal to 0\{40}, while refs to be deleted will have sha1-new equal to 0\{40}, otherwise sha1-old and sha1-new should be valid objects in the repository. +When accepting a signed push (see linkgit:git-push[1]), the signed +push certificate is stored in a blob and an environment variable +`GIT_PUSH_CERT` can be consulted for its object name. See the +description of `post-receive` hook for an example. In addition, the +certificate is verified using GPG and the result is exported with +the following environment variables: + +`GIT_PUSH_CERT_SIGNER`:: + The name and the e-mail address of the owner of the key that + signed the push certificate. + +`GIT_PUSH_CERT_KEY`:: + The GPG key ID of the key that signed the push certificate. + +`GIT_PUSH_CERT_STATUS`:: + The status of GPG verification of the push certificate, + using the same mnemonic as used in `%G?` format of `git log` + family of commands (see linkgit:git-log[1]). + +`GIT_PUSH_CERT_NONCE`:: + The nonce string the process asked the signer to include + in the push certificate. If this does not match the value + recorded on the "nonce" header in the push certificate, it + may indicate that the certificate is a valid one that is + being replayed from a separate "git push" session. + +`GIT_PUSH_CERT_NONCE_STATUS`:: +`UNSOLICITED`;; + "git push --signed" sent a nonce when we did not ask it to + send one. +`MISSING`;; + "git push --signed" did not send any nonce header. +`BAD`;; + "git push --signed" sent a bogus nonce. +`OK`;; + "git push --signed" sent the nonce we asked it to send. +`SLOP`;; + "git push --signed" sent a nonce different from what we + asked it to send now, but in a previous session. See + `GIT_PUSH_CERT_NONCE_SLOP` environment variable. + +`GIT_PUSH_CERT_NONCE_SLOP`:: + "git push --signed" sent a nonce different from what we + asked it to send now, but in a different session whose + starting time is different by this many seconds from the + current session. Only meaningful when + `GIT_PUSH_CERT_NONCE_STATUS` says `SLOP`. + Also read about `receive.certnonceslop` variable in + linkgit:git-config[1]. + This hook is called before any refname is updated and before any fast-forward checks are performed. @@ -101,9 +151,14 @@ the update. Refs that were created will have sha1-old equal to 0\{40}, otherwise sha1-old and sha1-new should be valid objects in the repository. +The `GIT_PUSH_CERT*` environment variables can be inspected, just as +in `pre-receive` hook, after accepting a signed push. + Using this hook, it is easy to generate mails describing the updates to the repository. This example script sends one mail message per -ref listing the commits pushed to the repository: +ref listing the commits pushed to the repository, and logs the push +certificates of signed pushes with good signatures to a logger +service: #!/bin/sh # mail out commit update information. @@ -119,6 +174,14 @@ ref listing the commits pushed to the repository: fi | mail -s "Changes to ref $ref" commit-list@mydomain done + # log signed push certificate, if any + if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G + then + ( + echo expected nonce is ${GIT_PUSH_NONCE} + git cat-file blob ${GIT_PUSH_CERT} + ) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain + fi exit 0 The exit code from this hook invocation is ignored, however a diff --git a/Documentation/git-remote-ext.txt b/Documentation/git-remote-ext.txt index cd0bb77..b25d0b5 100644 --- a/Documentation/git-remote-ext.txt +++ b/Documentation/git-remote-ext.txt @@ -116,6 +116,10 @@ begins with `ext::`. Examples: determined by the helper using environment variables (see above). +SEE ALSO +-------- +linkgit:gitremote-helpers[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt index bcd3766..e700baf 100644 --- a/Documentation/git-remote-fd.txt +++ b/Documentation/git-remote-fd.txt @@ -50,6 +50,10 @@ EXAMPLES `git push fd::7,8/bar master`:: Same as above. +SEE ALSO +-------- +linkgit:gitremote-helpers[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index cb103c8..4c6d6de 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -58,6 +58,9 @@ remote repository. With `--no-tags` option, `git fetch <name>` does not import tags from the remote repository. + +By default, only tags on fetched branches are imported +(see linkgit:git-fetch[1]). ++ With `-t <branch>` option, instead of the default glob refspec for the remote to track all branches under the `refs/remotes/<name>/` namespace, a refspec to track only `<branch>` @@ -130,17 +133,25 @@ branches, adds to that list. 'set-url':: -Changes URL remote points to. Sets first URL remote points to matching +Changes URLs for the remote. Sets first URL for remote <name> that matches regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If -<oldurl> doesn't match any URL, error occurs and nothing is changed. +<oldurl> doesn't match any URL, an error occurs and nothing is changed. + With '--push', push URLs are manipulated instead of fetch URLs. + -With '--add', instead of changing some URL, new URL is added. +With '--add', instead of changing existing URLs, new URL is added. ++ +With '--delete', instead of changing existing URLs, all URLs matching +regex <url> are deleted for remote <name>. Trying to delete all +non-push URLs is an error. + -With '--delete', instead of changing some URL, all URLs matching -regex <url> are deleted. Trying to delete all non-push URLs is an -error. +Note that the push URL and the fetch URL, even though they can +be set differently, must still refer to the same place. What you +pushed to the push URL should be what you would see if you +immediately fetched from the fetch URL. If you are trying to +fetch from one place (e.g. your upstream) and push to another (e.g. +your publishing repository), use two separate remotes. + 'show':: diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt index 7a1585d..5b11922 100644 --- a/Documentation/git-rev-list.txt +++ b/Documentation/git-rev-list.txt @@ -45,8 +45,9 @@ SYNOPSIS [ \--regexp-ignore-case | -i ] [ \--extended-regexp | -E ] [ \--fixed-strings | -F ] - [ \--date=(local|relative|default|iso|rfc|short) ] - [ [\--objects | \--objects-edge] [ \--unpacked ] ] + [ \--date=(local|relative|default|iso|iso-strict|rfc|short) ] + [ [ \--objects | \--objects-edge | \--objects-edge-aggressive ] + [ \--unpacked ] ] [ \--pretty | \--header ] [ \--bisect ] [ \--bisect-vars ] diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 0b84769..d6de42f 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -114,6 +114,7 @@ can be used. Only meaningful in `--verify` mode. Do not output an error message if the first argument is not a valid object name; instead exit with non-zero status silently. + SHA-1s for valid object names are printed to stdout on success. --sq:: Usually the output is made one line per flag and @@ -183,7 +184,7 @@ shown. If the pattern does not contain a globbing character (`?`, consider. Repetitions of this option accumulate exclusion patterns up to the next `--all`, `--branches`, `--tags`, `--remotes`, or `--glob` option (other options or arguments do not clear - accumlated patterns). + accumulated patterns). + The patterns given should not begin with `refs/heads`, `refs/tags`, or `refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`, diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index a60776e..f248a86 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -131,6 +131,21 @@ Note that no attempts whatsoever are made to validate the encoding. Specify encoding of compose message. Default is the value of the 'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed. +--transfer-encoding=(7bit|8bit|quoted-printable|base64):: + Specify the transfer encoding to be used to send the message over SMTP. + 7bit will fail upon encountering a non-ASCII message. quoted-printable + can be useful when the repository contains files that contain carriage + returns, but makes the raw patch email file (as saved from a MUA) much + harder to inspect manually. base64 is even more fool proof, but also + even more opaque. Default is the value of the 'sendemail.transferEncoding' + configuration value; if that is unspecified, git will use 8bit and not + add a Content-Transfer-Encoding header. + +--xmailer:: +--no-xmailer:: + Add (or prevent adding) the "X-Mailer:" header. By default, + the header is added, but it can be turned off by setting the + `sendemail.xmailer` configuration variable to `false`. Sending ~~~~~~~ @@ -199,10 +214,15 @@ must be used for each option. Legacy alias for '--smtp-encryption ssl'. --smtp-ssl-cert-path:: - Path to ca-certificates (either a directory or a single file). - Set it to an empty string to disable certificate verification. - Defaults to the value set to the 'sendemail.smtpsslcertpath' - configuration variable, if set, or `/etc/ssl/certs` otherwise. + Path to a store of trusted CA certificates for SMTP SSL/TLS + certificate validation (either a directory that has been processed + by 'c_rehash', or a single file containing one or more PEM format + certificates concatenated together: see verify(1) -CAfile and + -CApath for more information on these). Set it to an empty string + to disable certificate verification. Defaults to the value of the + 'sendemail.smtpsslcertpath' configuration variable, if set, or the + backing SSL library's compiled-in default otherwise (which should + be the best choice on most platforms). --smtp-user=<user>:: Username for SMTP-AUTH. Default is the value of 'sendemail.smtpuser'; diff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt index ba3fe0d..25bcda9 100644 --- a/Documentation/git-stage.txt +++ b/Documentation/git-stage.txt @@ -1,5 +1,5 @@ git-stage(1) -============== +============ NAME ---- diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index def635f..4d8d530 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -116,7 +116,7 @@ In the short-format, the status of each path is shown as where `PATH1` is the path in the `HEAD`, and the " `-> PATH2`" part is shown only when `PATH1` corresponds to a different path in the -index/worktree (i.e. the file is renamed). The 'XY' is a two-letter +index/worktree (i.e. the file is renamed). The `XY` is a two-letter status code. The fields (including the `->`) are separated from each other by a @@ -125,7 +125,7 @@ characters, that field will be quoted in the manner of a C string literal: surrounded by ASCII double quote (34) characters, and with interior special characters backslash-escaped. -For paths with merge conflicts, `X` and 'Y' show the modification +For paths with merge conflicts, `X` and `Y` show the modification states of each side of the merge. For paths that do not have merge conflicts, `X` shows the status of the index, and `Y` shows the status of the work tree. For untracked paths, `XY` are `??`. Other status diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt index c87bfcb..6c6e989 100644 --- a/Documentation/git-stripspace.txt +++ b/Documentation/git-stripspace.txt @@ -10,6 +10,7 @@ SYNOPSIS -------- [verse] 'git stripspace' [-s | --strip-comments] < input +'git stripspace' [-c | --comment-lines] < input DESCRIPTION ----------- diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 8e6af65..2c25916 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -154,27 +154,51 @@ If `--force` is specified, the submodule's work tree will be removed even if it contains local modifications. update:: - Update the registered submodules, i.e. clone missing submodules and - checkout the commit specified in the index of the containing repository. - This will make the submodules HEAD be detached unless `--rebase` or - `--merge` is specified or the key `submodule.$name.update` is set to - `rebase`, `merge` or `none`. `none` can be overridden by specifying - `--checkout`. Setting the key `submodule.$name.update` to `!command` - will cause `command` to be run. `command` can be any arbitrary shell - command that takes a single argument, namely the sha1 to update to. + +-- +Update the registered submodules to match what the superproject +expects by cloning missing submodules and updating the working tree of +the submodules. The "updating" can be done in several ways depending +on command line options and the value of `submodule.<name>.update` +configuration variable. Supported update procedures are: + + checkout;; the commit recorded in the superproject will be + checked out in the submodule on a detached HEAD. This is + done when `--checkout` option is given, or no option is + given, and `submodule.<name>.update` is unset, or if it is + set to 'checkout'. ++ +If `--force` is specified, the submodule will be checked out (using +`git checkout --force` if appropriate), even if the commit specified +in the index of the containing repository already matches the commit +checked out in the submodule. + + rebase;; the current branch of the submodule will be rebased + onto the commit recorded in the superproject. This is done + when `--rebase` option is given, or no option is given, and + `submodule.<name>.update` is set to 'rebase'. + + merge;; the commit recorded in the superproject will be merged + into the current branch in the submodule. This is done + when `--merge` option is given, or no option is given, and + `submodule.<name>.update` is set to 'merge'. + + custom command;; arbitrary shell command that takes a single + argument (the sha1 of the commit recorded in the + superproject) is executed. This is done when no option is + given, and `submodule.<name>.update` has the form of + '!command'. + +When no option is given and `submodule.<name>.update` is set to 'none', +the submodule is not updated. + If the submodule is not yet initialized, and you just want to use the setting as stored in .gitmodules, you can automatically initialize the submodule with the `--init` option. -+ + If `--recursive` is specified, this command will recurse into the registered submodules, and update any nested submodules within. -+ -If `--force` is specified, the submodule will be checked out (using -`git checkout --force` if appropriate), even if the commit specified in the -index of the containing repository already matches the commit checked out in -the submodule. - +-- summary:: Show commit summary between the given commit (defaults to HEAD) and working tree/index. For a submodule in question, a series of commits @@ -238,10 +262,12 @@ OPTIONS When running add, allow adding an otherwise ignored submodule path. When running deinit the submodule work trees will be removed even if they contain local changes. - When running update, throw away local changes in submodules when - switching to a different commit; and always run a checkout operation - in the submodule, even if the commit listed in the index of the - containing repository matches the commit checked out in the submodule. + When running update (only effective with the checkout procedure), + throw away local changes in submodules when switching to a + different commit; and always run a checkout operation in the + submodule, even if the commit listed in the index of the + containing repository matches the commit checked out in the + submodule. --cached:: This option is only valid for status and summary commands. These @@ -302,7 +328,7 @@ the submodule itself. Checkout the commit recorded in the superproject on a detached HEAD in the submodule. This is the default behavior, the main use of this option is to override `submodule.$name.update` when set to - `merge`, `rebase` or `none`. + a value other than `checkout`. If the key `submodule.$name.update` is either not explicitly set or set to `checkout`, this option is implicit. diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 44c970c..39e9a18 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -70,8 +70,8 @@ COMMANDS --username=<user>;; For transports that SVN handles authentication for (http, https, and plain svn), specify the username. For other - transports (eg svn+ssh://), you must include the username in - the URL, eg svn+ssh://foo@svn.bar.com/project + transports (e.g. svn+ssh://), you must include the username in + the URL, e.g. svn+ssh://foo@svn.bar.com/project --prefix=<prefix>;; This allows one to specify a prefix which is prepended to the names of remotes if trunk/branches/tags are @@ -252,6 +252,10 @@ Use of 'dcommit' is preferred to 'set-tree' (below). config key: svn-remote.<name>.commiturl config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options) + +Note that the SVN URL of the commiturl config key includes the SVN branch. +If you rather want to set the commit URL for an entire SVN repository use +svn-remote.<name>.pushurl instead. ++ Using this option for any other purpose (don't ask) is very strongly discouraged. @@ -386,11 +390,13 @@ Any other arguments are passed directly to 'git log' tree-ish to specify which branch should be searched). When given a tree-ish, returns the corresponding SVN revision number. + +-B;; --before;; Don't require an exact match if given an SVN revision, instead find the commit corresponding to the state of the SVN repository (on the current branch) at the specified revision. + +-A;; --after;; Don't require an exact match if given an SVN revision; if there is not an exact match return the closest match searching forward in the @@ -608,21 +614,6 @@ config key: svn.authorsfile Make 'git svn' less verbose. Specify a second time to make it even less verbose. ---repack[=<n>]:: ---repack-flags=<flags>:: - These should help keep disk usage sane for large fetches with - many revisions. -+ ---repack takes an optional argument for the number of revisions -to fetch before repacking. This defaults to repacking every -1000 commits fetched if no argument is specified. -+ ---repack-flags are passed directly to 'git repack'. -+ -[verse] -config key: svn.repack -config key: svn.repackflags - -m:: --merge:: -s<strategy>:: diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index dfc09d9..aff0179 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -82,20 +82,18 @@ OPTIONS Set the execute permissions on the updated files. --[no-]assume-unchanged:: - When these flags are specified, the object names recorded - for the paths are not updated. Instead, these options - set and unset the "assume unchanged" bit for the - paths. When the "assume unchanged" bit is on, Git stops - checking the working tree files for possible - modifications, so you need to manually unset the bit to - tell Git when you change the working tree file. This is + When this flag is specified, the object names recorded + for the paths are not updated. Instead, this option + sets/unsets the "assume unchanged" bit for the + paths. When the "assume unchanged" bit is on, the user + promises not to change the file and allows Git to assume + that the working tree file matches what is recorded in + the index. If you want to change the working tree file, + you need to unset the bit to tell Git. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs). + -This option can be also used as a coarse file-level mechanism -to ignore uncommitted changes in tracked files (akin to what -`.gitignore` does for untracked files). Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, @@ -170,7 +168,7 @@ may not support it yet. split-index mode is already enabled and `--split-index` is given again, all changes in $GIT_DIR/index are pushed back to the shared index file. This mode is designed for very large - indexes that take a signficant amount of time to read or write. + indexes that take a significant amount of time to read or write. \--:: Do not interpret any more arguments as options. @@ -202,7 +200,7 @@ merging. To pretend you have a file with mode and sha1 at path, say: ---------------- -$ git update-index --cacheinfo mode sha1 path +$ git update-index --cacheinfo <mode>,<sha1>,<path> ---------------- '--info-only' is used to register files without placing them in the object diff --git a/Documentation/git.txt b/Documentation/git.txt index 5627845..8f5220c 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -22,7 +22,7 @@ unusually rich command set that provides both high-level operations and full access to internals. See linkgit:gittutorial[7] to get started, then see -link:everyday.html[Everyday Git] for a useful minimum set of +linkgit:giteveryday[7] for a useful minimum set of commands. The link:user-manual.html[Git User's Manual] has a more in-depth introduction. @@ -43,35 +43,56 @@ unreleased) version of Git, that is available from the 'master' branch of the `git.git` repository. Documentation for older releases are available here: -* link:v2.1.3/git.html[documentation for release 2.1.3] +* link:v2.3.5/git.html[documentation for release 2.3.5] * release notes for + link:RelNotes/2.3.5.txt[2.3.5], + link:RelNotes/2.3.4.txt[2.3.4], + link:RelNotes/2.3.3.txt[2.3.3], + link:RelNotes/2.3.2.txt[2.3.2], + link:RelNotes/2.3.1.txt[2.3.1], + link:RelNotes/2.3.0.txt[2.3]. + +* link:v2.2.2/git.html[documentation for release 2.2.2] + +* release notes for + link:RelNotes/2.2.2.txt[2.2.2], + link:RelNotes/2.2.1.txt[2.2.1], + link:RelNotes/2.2.0.txt[2.2]. + +* link:v2.1.4/git.html[documentation for release 2.1.4] + +* release notes for + link:RelNotes/2.1.4.txt[2.1.4], link:RelNotes/2.1.3.txt[2.1.3], link:RelNotes/2.1.2.txt[2.1.2], link:RelNotes/2.1.1.txt[2.1.1], link:RelNotes/2.1.0.txt[2.1]. -* link:v2.0.4/git.html[documentation for release 2.0.4] +* link:v2.0.5/git.html[documentation for release 2.0.5] * release notes for + link:RelNotes/2.0.5.txt[2.0.5], link:RelNotes/2.0.4.txt[2.0.4], link:RelNotes/2.0.3.txt[2.0.3], link:RelNotes/2.0.2.txt[2.0.2], link:RelNotes/2.0.1.txt[2.0.1], link:RelNotes/2.0.0.txt[2.0.0]. -* link:v1.9.4/git.html[documentation for release 1.9.4] +* link:v1.9.5/git.html[documentation for release 1.9.5] * release notes for + link:RelNotes/1.9.5.txt[1.9.5], link:RelNotes/1.9.4.txt[1.9.4], link:RelNotes/1.9.3.txt[1.9.3], link:RelNotes/1.9.2.txt[1.9.2], link:RelNotes/1.9.1.txt[1.9.1], link:RelNotes/1.9.0.txt[1.9.0]. -* link:v1.8.5.5/git.html[documentation for release 1.8.5.5] +* link:v1.8.5.6/git.html[documentation for release 1.8.5.6] * release notes for + link:RelNotes/1.8.5.6.txt[1.8.5.6], link:RelNotes/1.8.5.5.txt[1.8.5.5], link:RelNotes/1.8.5.4.txt[1.8.5.4], link:RelNotes/1.8.5.3.txt[1.8.5.3], @@ -749,7 +770,8 @@ Git so take care if using Cogito etc. 'GIT_INDEX_VERSION':: This environment variable allows the specification of an index version for new repositories. It won't affect existing index - files. By default index file version [23] is used. + files. By default index file version 2 or 3 is used. See + linkgit:git-update-index[1] for more information. 'GIT_OBJECT_DIRECTORY':: If the object storage directory is specified via this @@ -876,19 +898,21 @@ other and the `core.editor` option in linkgit:git-config[1]. 'GIT_SSH':: - If this environment variable is set then 'git fetch' - and 'git push' will use this command instead - of 'ssh' when they need to connect to a remote system. - The '$GIT_SSH' command will be given exactly two or - four arguments: the 'username@host' (or just 'host') - from the URL and the shell command to execute on that - remote system, optionally preceded by '-p' (literally) and - the 'port' from the URL when it specifies something other - than the default SSH port. +'GIT_SSH_COMMAND':: + If either of these environment variables is set then 'git fetch' + and 'git push' will use the specified command instead of 'ssh' + when they need to connect to a remote system. + The command will be given exactly two or four arguments: the + 'username@host' (or just 'host') from the URL and the shell + command to execute on that remote system, optionally preceded by + '-p' (literally) and the 'port' from the URL when it specifies + something other than the default SSH port. + -To pass options to the program that you want to list in GIT_SSH -you will need to wrap the program and options into a shell script, -then set GIT_SSH to refer to the shell script. +`$GIT_SSH_COMMAND` takes precedence over `$GIT_SSH`, and is interpreted +by the shell, which allows additional arguments to be included. +`$GIT_SSH` on the other hand must be just the path to a program +(which can be a wrapper shell script, if additional arguments are +needed). + Usually it is easier to configure any desired options through your personal `.ssh/config` file. Please consult your ssh documentation @@ -901,6 +925,10 @@ for further details. and read the password from its STDOUT. See also the 'core.askpass' option in linkgit:git-config[1]. +'GIT_TERMINAL_PROMPT':: + If this environment variable is set to `0`, git will not prompt + on the terminal (e.g., when asking for HTTP authentication). + 'GIT_CONFIG_NOSYSTEM':: Whether to skip reading settings from the system-wide `$(prefix)/etc/gitconfig` file. This environment variable can @@ -1001,6 +1029,17 @@ GIT_ICASE_PATHSPECS:: variable when it is invoked as the top level command by the end user, to be recorded in the body of the reflog. +`GIT_REF_PARANOIA`:: + If set to `1`, include broken or badly named refs when iterating + over lists of refs. In a normal, non-corrupted repository, this + does nothing. However, enabling it may help git to detect and + abort some operations in the presence of broken refs. Git sets + this variable automatically when performing destructive + operations like linkgit:git-prune[1]. You should not need to set + it yourself unless you want to be paranoid about making sure + an operation has touched every ref (e.g., because you are + cloning a repository to make a backup). + Discussion[[Discussion]] ------------------------ @@ -1099,7 +1138,7 @@ subscribed to the list to send a message there. SEE ALSO -------- linkgit:gittutorial[7], linkgit:gittutorial-2[7], -link:everyday.html[Everyday Git], linkgit:gitcvs-migration[7], +linkgit:giteveryday[7], linkgit:gitcvs-migration[7], linkgit:gitglossary[7], linkgit:gitcore-tutorial[7], linkgit:gitcli[7], link:user-manual.html[The Git User's Manual], linkgit:gitworkflows[7] diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 643c1ba..c892ffa 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -440,8 +440,8 @@ Unspecified:: A path to which the `diff` attribute is unspecified first gets its contents inspected, and if it looks like - text, it is treated as text. Otherwise it would - generate `Binary files differ`. + text and is smaller than core.bigFileThreshold, it is treated + as text. Otherwise it would generate `Binary files differ`. String:: @@ -665,7 +665,7 @@ data by examining the beginning of the contents. However, sometimes you may want to override its decision, either because a blob contains binary data later in the file, or because the content, while technically composed of text characters, is opaque to a human reader. For example, -many postscript files contain only ascii characters, but produce noisy +many postscript files contain only ASCII characters, but produce noisy and meaningless diffs. The simplest way to mark a file as binary is to unset the diff @@ -680,7 +680,7 @@ patch, if binary patches are enabled) instead of a regular diff. However, one may also want to specify other diff driver attributes. For example, you might want to use `textconv` to convert postscript files to -an ascii representation for human viewing, but otherwise treat them as +an ASCII representation for human viewing, but otherwise treat them as binary files. You cannot specify both `-diff` and `diff=ps` attributes. The solution is to use the `diff.*.binary` config option: diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index d2d7c21..8475c07 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -1667,7 +1667,7 @@ linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcvs-migration[7], linkgit:git-help[1], -link:everyday.html[Everyday git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt index 5f4e890..b06e852 100644 --- a/Documentation/gitcvs-migration.txt +++ b/Documentation/gitcvs-migration.txt @@ -194,7 +194,7 @@ linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], -link:everyday.html[Everyday Git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/everyday.txt b/Documentation/giteveryday.txt index b2548ef..7be6e64 100644 --- a/Documentation/everyday.txt +++ b/Documentation/giteveryday.txt @@ -1,22 +1,37 @@ +giteveryday(7) +=============== + +NAME +---- +giteveryday - A useful minimum set of commands for Everyday Git + +SYNOPSIS +-------- + Everyday Git With 20 Commands Or So -=================================== -<<Individual Developer (Standalone)>> commands are essential for -anybody who makes a commit, even for somebody who works alone. +DESCRIPTION +----------- -If you work with other people, you will need commands listed in -the <<Individual Developer (Participant)>> section as well. +Git users can broadly be grouped into four categories for the purposes of +describing here a small set of useful command for everyday Git. -People who play the <<Integrator>> role need to learn some more -commands in addition to the above. +* <<STANDALONE,Individual Developer (Standalone)>> commands are essential + for anybody who makes a commit, even for somebody who works alone. -<<Repository Administration>> commands are for system -administrators who are responsible for the care and feeding -of Git repositories. +* If you work with other people, you will need commands listed in + the <<PARTICIPANT,Individual Developer (Participant)>> section as well. +* People who play the <<INTEGRATOR,Integrator>> role need to learn some + more commands in addition to the above. -Individual Developer (Standalone)[[Individual Developer (Standalone)]] ----------------------------------------------------------------------- +* <<ADMINISTRATION,Repository Administration>> commands are for system + administrators who are responsible for the care and feeding + of Git repositories. + + +Individual Developer (Standalone)[[STANDALONE]] +----------------------------------------------- A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the @@ -24,8 +39,6 @@ following commands. * linkgit:git-init[1] to create a new repository. - * linkgit:git-show-branch[1] to see where you are. - * linkgit:git-log[1] to see what happened. * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch @@ -45,7 +58,7 @@ following commands. * linkgit:git-rebase[1] to maintain topic branches. - * linkgit:git-tag[1] to mark known point. + * linkgit:git-tag[1] to mark a known point. Examples ~~~~~~~~ @@ -75,14 +88,12 @@ $ edit/compile/test $ git diff HEAD <4> $ git commit -a -s <5> $ edit/compile/test -$ git reset --soft HEAD^ <6> -$ edit/compile/test -$ git diff ORIG_HEAD <7> -$ git commit -a -c ORIG_HEAD <8> -$ git checkout master <9> -$ git merge alsa-audio <10> -$ git log --since='3 days ago' <11> -$ git log v2.43.. curses/ <12> +$ git diff HEAD^ <6> +$ git commit -a --amend <7> +$ git checkout master <8> +$ git merge alsa-audio <9> +$ git log --since='3 days ago' <10> +$ git log v2.43.. curses/ <11> ------------ + <1> create a new topic branch. @@ -90,22 +101,21 @@ $ git log v2.43.. curses/ <12> <3> you need to tell Git if you added a new file; removal and modification will be caught if you do `git commit -a` later. <4> to see what changes you are committing. -<5> commit everything as you have tested, with your sign-off. -<6> take the last commit back, keeping what is in the working tree. -<7> look at the changes since the premature commit we took back. -<8> redo the commit undone in the previous step, using the message -you originally wrote. -<9> switch to the master branch. -<10> merge a topic branch into your master branch. -<11> review commit logs; other forms to limit output can be -combined and include `--max-count=10` (show 10 commits), +<5> commit everything, as you have tested, with your sign-off. +<6> look at all your changes including the previous commit. +<7> amend the previous commit, adding all your new changes, +using your original message. +<8> switch to the master branch. +<9> merge a topic branch into your master branch. +<10> review commit logs; other forms to limit output can be +combined and include `-10` (to show up to 10 commits), `--until=2005-12-10`, etc. -<12> view only the changes that touch what's in `curses/` +<11> view only the changes that touch what's in `curses/` directory, since `v2.43` tag. -Individual Developer (Participant)[[Individual Developer (Participant)]] ------------------------------------------------------------------------- +Individual Developer (Participant)[[PARTICIPANT]] +------------------------------------------------- A developer working as a participant in a group project needs to learn how to communicate with others, and uses these commands in @@ -123,6 +133,13 @@ addition to the ones needed by a standalone developer. * linkgit:git-format-patch[1] to prepare e-mail submission, if you adopt Linux kernel-style public forum workflow. + * linkgit:git-send-email[1] to send your e-mail submission without + corruption by your MUA. + + * linkgit:git-request-pull[1] to create a summary of changes + for your upstream to pull. + + Examples ~~~~~~~~ @@ -131,28 +148,34 @@ Clone the upstream and work on it. Feed changes to upstream.:: ------------ $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 $ cd my2.6 -$ edit/compile/test; git commit -a -s <1> -$ git format-patch origin <2> -$ git pull <3> -$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4> -$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5> -$ git reset --hard ORIG_HEAD <6> -$ git gc <7> -$ git fetch --tags <8> +$ git checkout -b mine master <1> +$ edit/compile/test; git commit -a -s <2> +$ git format-patch master <3> +$ git send-email --to="person <email@example.com>" 00*.patch <4> +$ git checkout master <5> +$ git pull <6> +$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <7> +$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git <8> +$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <9> +$ git reset --hard ORIG_HEAD <10> +$ git gc <11> ------------ + -<1> repeat as needed. -<2> extract patches from your branch for e-mail submission. -<3> `git pull` fetches from `origin` by default and merges into the +<1> checkout a new branch `mine` from master. +<2> repeat as needed. +<3> extract patches from your branch, relative to master, +<4> and email them. +<5> return to `master`, ready to see what's new +<6> `git pull` fetches from `origin` by default and merges into the current branch. -<4> immediately after pulling, look at the changes done upstream +<7> immediately after pulling, look at the changes done upstream since last time we checked, only in the area we are interested in. -<5> fetch from a specific branch from a specific repository and merge. -<6> revert the pull. -<7> garbage collect leftover objects from reverted pull. -<8> from time to time, obtain official tags from the `origin` -and store them under `.git/refs/tags/`. +<8> check the branch names in an external repository (if not known). +<9> fetch from a specific branch `ALL` from a specific repository +and merge it. +<10> revert the pull. +<11> garbage collect leftover objects from reverted pull. Push into another repository.:: @@ -166,7 +189,7 @@ remote.origin.fetch refs/heads/*:refs/remotes/origin/* branch.master.remote origin branch.master.merge refs/heads/master satellite$ git config remote.origin.push \ - master:refs/remotes/satellite/master <3> + +refs/heads/*:refs/remotes/satellite/* <3> satellite$ edit/compile/test/commit satellite$ git push origin <4> @@ -181,11 +204,12 @@ machine. <2> clone sets these configuration variables by default. It arranges `git pull` to fetch and store the branches of mothership machine to local `remotes/origin/*` remote-tracking branches. -<3> arrange `git push` to push local `master` branch to -`remotes/satellite/master` branch of the mothership machine. -<4> push will stash our work away on `remotes/satellite/master` -remote-tracking branch on the mothership machine. You could use this -as a back-up method. +<3> arrange `git push` to push all local branches to +their corresponding branch of the mothership machine. +<4> push will stash all our work away on `remotes/satellite/*` +remote-tracking branches on the mothership machine. You could use this +as a back-up method. Likewise, you can pretend that mothership +"fetched" from you (useful when access is one sided). <5> on mothership machine, merge the work done on the satellite machine into the master branch. @@ -195,17 +219,22 @@ Branch off of a specific tag.:: $ git checkout -b private2.6.14 v2.6.14 <1> $ edit/compile/test; git commit -a $ git checkout master -$ git format-patch -k -m --stdout v2.6.14..private2.6.14 | - git am -3 -k <2> +$ git cherry-pick v2.6.14..private2.6.14 <2> ------------ + <1> create a private branch based on a well known (but somewhat behind) tag. <2> forward port all changes in `private2.6.14` branch to `master` branch -without a formal "merging". +without a formal "merging". Or longhand + +`git format-patch -k -m --stdout v2.6.14..private2.6.14 | + git am -3 -k` +An alternate participant submission mechanism is using the +`git request-pull` or pull-request mechanisms (e.g as used on +GitHub (www.github.com) to notify your upstream of your +contribution. -Integrator[[Integrator]] +Integrator[[INTEGRATOR]] ------------------------ A fairly central person acting as the integrator in a group @@ -213,6 +242,13 @@ project receives changes made by others, reviews and integrates them and publishes the result for others to use, using these commands in addition to the ones needed by participants. +This section can also be used by those who respond to `git +request-pull` or pull-request on GitHub (www.github.com) to +integrate the work of others into their history. An sub-area +lieutenant for a repository will act both as a participant and +as an integrator. + + * linkgit:git-am[1] to apply patches e-mailed in from your contributors. @@ -229,19 +265,19 @@ commands in addition to the ones needed by participants. Examples ~~~~~~~~ -My typical Git day.:: +A typical integrator's Git day.:: + ------------ $ git status <1> -$ git show-branch <2> +$ git branch --no-merged master <2> $ mailx <3> & s 2 3 4 5 ./+to-apply & s 7 8 ./+hold-linus & q $ git checkout -b topic/one master -$ git am -3 -i -s -u ./+to-apply <4> +$ git am -3 -i -s ./+to-apply <4> $ compile/test -$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5> +$ git checkout -b hold/linus && git am -3 -i -s ./+hold-linus <5> $ git checkout topic/one && git rebase master <6> $ git checkout pu && git reset --hard next <7> $ git merge topic/one topic/two && git merge hold/linus <8> @@ -249,51 +285,51 @@ $ git checkout maint $ git cherry-pick master~4 <9> $ compile/test $ git tag -s -m "GIT 0.99.9x" v0.99.9x <10> -$ git fetch ko && git show-branch master maint 'tags/ko-*' <11> -$ git push ko <12> -$ git push ko v0.99.9x <13> +$ git fetch ko && for branch in master maint next pu <11> + do + git show-branch ko/$branch $branch <12> + done +$ git push --follow-tags ko <13> ------------ + -<1> see what I was in the middle of doing, if any. -<2> see what topic branches I have and think about how ready -they are. +<1> see what you were in the middle of doing, if anything. +<2> see which branches haven't been merged into `master` yet. +Likewise for any other integration branches e.g. `maint`, `next` +and `pu` (potential updates). <3> read mails, save ones that are applicable, and save others -that are not quite ready. -<4> apply them, interactively, with my sign-offs. -<5> create topic branch as needed and apply, again with my -sign-offs. +that are not quite ready (other mail readers are available). +<4> apply them, interactively, with your sign-offs. +<5> create topic branch as needed and apply, again with sign-offs. <6> rebase internal topic branch that has not been merged to the master or exposed as a part of a stable branch. <7> restart `pu` every time from the next. <8> and bundle topic branches still cooking. <9> backport a critical fix. <10> create a signed tag. -<11> make sure I did not accidentally rewind master beyond what I -already pushed out. `ko` shorthand points at the repository I have -at kernel.org, and looks like this: +<11> make sure master was not accidentally rewound beyond that +already pushed out. `ko` shorthand points at the Git maintainer's +repository at kernel.org, and looks like this: + ------------ -$ cat .git/remotes/ko -URL: kernel.org:/pub/scm/git/git.git -Pull: master:refs/tags/ko-master -Pull: next:refs/tags/ko-next -Pull: maint:refs/tags/ko-maint -Push: master -Push: next -Push: +pu -Push: maint +(in .git/config) +[remote "ko"] + url = kernel.org:/pub/scm/git/git.git + fetch = refs/heads/*:refs/remotes/ko/* + push = refs/heads/master + push = refs/heads/next + push = +refs/heads/pu + push = refs/heads/maint ------------ + -In the output from `git show-branch`, `master` should have -everything `ko-master` has, and `next` should have -everything `ko-next` has. - -<12> push out the bleeding edge. -<13> push the tag out, too. +<12> In the output from `git show-branch`, `master` should have +everything `ko/master` has, and `next` should have +everything `ko/next` has, etc. +<13> push out the bleeding edge, together with new tags that point +into the pushed history. -Repository Administration[[Repository Administration]] ------------------------------------------------------- +Repository Administration[[ADMINISTRATION]] +------------------------------------------- A repository administrator uses the following tools to set up and maintain access to the repository by developers. @@ -304,9 +340,19 @@ and maintain access to the repository by developers. * linkgit:git-shell[1] can be used as a 'restricted login shell' for shared central repository users. + * linkgit:git-http-backend[1] provides a server side implementation + of Git-over-HTTP ("Smart http") allowing both fetch and push services. + + * linkgit:gitweb[1] provides a web front-end to Git repositories, + which can be set-up using the linkgit:git-instaweb[1] script. + link:howto/update-hook-example.html[update hook howto] has a good example of managing a shared central repository. +In addition there are a number of other widely deployed hosting, browsing +and reviewing solutions such as: + + * gitolite, gerrit code review, cgit and others. Examples ~~~~~~~~ @@ -335,22 +381,25 @@ $ cat /etc/xinetd.d/git-daemon # description: The Git server offers access to Git repositories service git { - disable = no - type = UNLISTED - port = 9418 - socket_type = stream - wait = no - user = nobody - server = /usr/bin/git-daemon - server_args = --inetd --export-all --base-path=/pub/scm - log_on_failure += USERID + disable = no + type = UNLISTED + port = 9418 + socket_type = stream + wait = no + user = nobody + server = /usr/bin/git-daemon + server_args = --inetd --export-all --base-path=/pub/scm + log_on_failure += USERID } ------------ + Check your xinetd(8) documentation and setup, this is from a Fedora system. Others might be different. -Give push/pull only access to developers.:: +Give push/pull only access to developers using git-over-ssh.:: + +e.g. those using: +`$ git push/pull ssh://host.xz/pub/scm/project` + ------------ $ grep git /etc/passwd <1> @@ -363,8 +412,8 @@ $ grep git /etc/shells <2> ------------ + <1> log-in shell is set to /usr/bin/git-shell, which does not -allow anything but `git push` and `git pull`. The users should -get an ssh access to the machine. +allow anything but `git push` and `git pull`. The users require +ssh access to the machine. <2> in many distributions /etc/shells needs to list what is used as the login shell. @@ -401,13 +450,6 @@ for branch policy control. david is the release manager and is the only person who can create and push version tags. -HTTP server to support dumb protocol transfer.:: -+ ------------- -dev$ git update-server-info <1> -dev$ ftp user@isp.example.com <2> -ftp> cp -r .git /home/user/myproject.git ------------- -+ -<1> make sure your info/refs and objects/info/packs are up-to-date -<2> upload to public HTTP server hosted by your ISP. +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt index e52de7d..212e254 100644 --- a/Documentation/gitglossary.txt +++ b/Documentation/gitglossary.txt @@ -19,7 +19,7 @@ SEE ALSO linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcvs-migration[7], -link:everyday.html[Everyday Git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index d954bf6..9ef2469 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -175,7 +175,7 @@ if the merge failed due to conflicts. This hook can be used in conjunction with a corresponding pre-commit hook to save and restore any form of metadata associated with the working tree -(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl +(e.g.: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl for an example of how to do this. pre-push diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 09e82c3..4fd0442 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -138,9 +138,6 @@ NOTES The purpose of gitignore files is to ensure that certain files not tracked by Git remain untracked. -To ignore uncommitted changes in a file that is already tracked, -use 'git update-index {litdd}assume-unchanged'. - To stop tracking a file that is currently tracked, use 'git rm --cached'. @@ -203,7 +200,6 @@ everything within `foo/bar`): SEE ALSO -------- linkgit:git-rm[1], -linkgit:git-update-index[1], linkgit:gitrepository-layout[5], linkgit:git-check-ignore[1] diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt index f6c0dfd..ac70eca 100644 --- a/Documentation/gitmodules.txt +++ b/Documentation/gitmodules.txt @@ -38,18 +38,15 @@ submodule.<name>.url:: In addition, there are a number of optional keys: submodule.<name>.update:: - Defines what to do when the submodule is updated by the superproject. - If 'checkout' (the default), the new commit specified in the - superproject will be checked out in the submodule on a detached HEAD. - If 'rebase', the current branch of the submodule will be rebased onto - the commit specified in the superproject. If 'merge', the commit - specified in the superproject will be merged into the current branch - in the submodule. - If 'none', the submodule with name `$name` will not be updated - by default. - - This config option is overridden if 'git submodule update' is given - the '--merge', '--rebase' or '--checkout' options. + Defines the default update procedure for the named submodule, + i.e. how the submodule is updated by "git submodule update" + command in the superproject. This is only used by `git + submodule init` to initialize the configuration variable of + the same name. Allowed values here are 'checkout', 'rebase', + 'merge' or 'none'. See description of 'update' command in + linkgit:git-submodule[1] for their meaning. Note that the + '!command' form is intentionally ignored here for security + reasons. submodule.<name>.branch:: A remote branch name for tracking updates in the upstream submodule. diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt index 64f7ad2..8edf72c 100644 --- a/Documentation/gitremote-helpers.txt +++ b/Documentation/gitremote-helpers.txt @@ -452,8 +452,14 @@ SEE ALSO -------- linkgit:git-remote[1] +linkgit:git-remote-ext[1] + +linkgit:git-remote-fd[1] + linkgit:git-remote-testgit[1] +linkgit:git-fast-import[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt index 3109ea8..30d2119 100644 --- a/Documentation/gittutorial-2.txt +++ b/Documentation/gittutorial-2.txt @@ -368,17 +368,18 @@ situation: ------------------------------------------------ $ git status -# On branch master -# Changes to be committed: -# (use "git reset HEAD <file>..." to unstage) -# -# new file: closing.txt -# -# Changes not staged for commit: -# (use "git add <file>..." to update what will be committed) -# -# modified: file.txt -# +On branch master +Changes to be committed: + (use "git reset HEAD <file>..." to unstage) + + new file: closing.txt + +Changes not staged for commit: + (use "git add <file>..." to update what will be committed) + (use "git checkout -- <file>..." to discard changes in working directory) + + modified: file.txt + ------------------------------------------------ Since the current state of closing.txt is cached in the index file, @@ -403,7 +404,7 @@ What next? At this point you should know everything necessary to read the man pages for any of the git commands; one good place to start would be -with the commands mentioned in link:everyday.html[Everyday Git]. You +with the commands mentioned in linkgit:giteveryday[7]. You should be able to find any unknown jargon in linkgit:gitglossary[7]. The link:user-manual.html[Git User's Manual] provides a more @@ -427,7 +428,7 @@ linkgit:gitcvs-migration[7], linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], linkgit:git-help[1], -link:everyday.html[Everyday Git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 8262196..b00c67d 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -3,7 +3,7 @@ gittutorial(7) NAME ---- -gittutorial - A tutorial introduction to Git (for version 1.5.1 or newer) +gittutorial - A tutorial introduction to Git SYNOPSIS -------- @@ -107,14 +107,15 @@ summary of the situation with 'git status': ------------------------------------------------ $ git status -# On branch master -# Changes to be committed: -# (use "git reset HEAD <file>..." to unstage) -# -# modified: file1 -# modified: file2 -# modified: file3 -# +On branch master +Changes to be committed: +Your branch is up-to-date with 'origin/master'. + (use "git reset HEAD <file>..." to unstage) + + modified: file1 + modified: file2 + modified: file3 + ------------------------------------------------ If you need to make any further adjustments, do so now, and then add any @@ -656,7 +657,7 @@ digressions that may be interesting at this point are: * linkgit:gitworkflows[7]: Gives an overview of recommended workflows. - * link:everyday.html[Everyday Git with 20 Commands Or So] + * linkgit:giteveryday[7]: Everyday Git with 20 Commands Or So. * linkgit:gitcvs-migration[7]: Git for CVS users. @@ -668,7 +669,7 @@ linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], linkgit:git-help[1], linkgit:gitworkflows[7], -link:everyday.html[Everyday Git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index ebe7a6c..b96ac72 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -482,7 +482,7 @@ project config. Per-repository configuration takes precedence over value composed from `@git_base_url_list` elements and project name. + You can setup one single value (single entry/item in this list) at build -time by setting the `GITWEB_BASE_URL` built-time configuration variable. +time by setting the `GITWEB_BASE_URL` build-time configuration variable. By default it is set to (), i.e. an empty list. This means that gitweb would not try to create project URL (to fetch) from project name. diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 4e0b971..bf383c2 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -329,7 +329,7 @@ short form, the leading colon `:` is followed by zero or more "magic signature" letters (which optionally is terminated by another colon `:`), and the remainder is the pattern to match against the path. The "magic signature" consists of ASCII symbols that are neither -alphanumeric, glob, regex special charaters nor colon. +alphanumeric, glob, regex special characters nor colon. The optional colon that terminates the "magic signature" can be omitted if the pattern begins with a character that does not belong to "magic signature" symbol set and is not a colon. diff --git a/Documentation/howto/recover-corrupted-object-harder.txt b/Documentation/howto/recover-corrupted-object-harder.txt index 6f33dac..9c4cd09 100644 --- a/Documentation/howto/recover-corrupted-object-harder.txt +++ b/Documentation/howto/recover-corrupted-object-harder.txt @@ -38,7 +38,7 @@ zlib were failing). Reading the zlib source code, I found that "incorrect data check" means that the adler-32 checksum at the end of the zlib data did not match the inflated data. So stepping the data through zlib would not help, as it -did not fail until the very end, when we realize the crc does not match. +did not fail until the very end, when we realize the CRC does not match. The problematic bytes could be anywhere in the object data. The first thing I did was pull the broken data out of the packfile. I @@ -195,7 +195,7 @@ halfway through: ------- I let it run to completion, and got a few more hits at the end (where it -was munging the crc to match our broken data). So there was a good +was munging the CRC to match our broken data). So there was a good chance this middle hit was the source of the problem. I confirmed by tweaking the byte in a hex editor, zlib inflating the @@ -240,3 +240,240 @@ But more importantly, git's hashing and checksumming noticed a problem that easily could have gone undetected in another system. The result still compiled, but would have caused an interesting bug (that would have been blamed on some random commit). + + +The adventure continues... +-------------------------- + +I ended up doing this again! Same entity, new hardware. The assumption +at this point is that the old disk corrupted the packfile, and then the +corruption was migrated to the new hardware (because it was done by +rsync or similar, and no fsck was done at the time of migration). + +This time, the affected blob was over 20 megabytes, which was far too +large to do a brute-force on. I followed the instructions above to +create the `zlib` file. I then used the `inflate` program below to pull +the corrupted data from that. Examining that output gave me a hint about +where in the file the corruption was. But now I was working with the +file itself, not the zlib contents. So knowing the sha1 of the object +and the approximate area of the corruption, I used the `sha1-munge` +program below to brute-force the correct byte. + +Here's the inflate program (it's essentially `gunzip` but without the +`.gz` header processing): + +-------------------------- +#include <stdio.h> +#include <string.h> +#include <zlib.h> +#include <stdlib.h> + +int main(int argc, char **argv) +{ + /* + * oversized so we can read the whole buffer in; + * this could actually be switched to streaming + * to avoid any memory limitations + */ + static unsigned char buf[25 * 1024 * 1024]; + static unsigned char out[25 * 1024 * 1024]; + int len; + z_stream z; + int ret; + + len = read(0, buf, sizeof(buf)); + memset(&z, 0, sizeof(z)); + inflateInit(&z); + + z.next_in = buf; + z.avail_in = len; + z.next_out = out; + z.avail_out = sizeof(out); + + ret = inflate(&z, 0); + if (ret != Z_OK && ret != Z_STREAM_END) + fprintf(stderr, "initial inflate failed (%d)\n", ret); + + fprintf(stderr, "outputting %lu bytes", z.total_out); + fwrite(out, 1, z.total_out, stdout); + return 0; +} +-------------------------- + +And here is the `sha1-munge` program: + +-------------------------- +#include <stdio.h> +#include <unistd.h> +#include <string.h> +#include <signal.h> +#include <openssl/sha.h> +#include <stdlib.h> + +/* eye candy */ +static int counter = 0; +static void progress(int sig) +{ + fprintf(stderr, "\r%d", counter); + alarm(1); +} + +static const signed char hexval_table[256] = { + -1, -1, -1, -1, -1, -1, -1, -1, /* 00-07 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 08-0f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 10-17 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 18-1f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 20-27 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 28-2f */ + 0, 1, 2, 3, 4, 5, 6, 7, /* 30-37 */ + 8, 9, -1, -1, -1, -1, -1, -1, /* 38-3f */ + -1, 10, 11, 12, 13, 14, 15, -1, /* 40-47 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 48-4f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 50-57 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 58-5f */ + -1, 10, 11, 12, 13, 14, 15, -1, /* 60-67 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 68-67 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 70-77 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 78-7f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 80-87 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 88-8f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 90-97 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 98-9f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* a0-a7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* a8-af */ + -1, -1, -1, -1, -1, -1, -1, -1, /* b0-b7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* b8-bf */ + -1, -1, -1, -1, -1, -1, -1, -1, /* c0-c7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* c8-cf */ + -1, -1, -1, -1, -1, -1, -1, -1, /* d0-d7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* d8-df */ + -1, -1, -1, -1, -1, -1, -1, -1, /* e0-e7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* e8-ef */ + -1, -1, -1, -1, -1, -1, -1, -1, /* f0-f7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* f8-ff */ +}; + +static inline unsigned int hexval(unsigned char c) +{ +return hexval_table[c]; +} + +static int get_sha1_hex(const char *hex, unsigned char *sha1) +{ + int i; + for (i = 0; i < 20; i++) { + unsigned int val; + /* + * hex[1]=='\0' is caught when val is checked below, + * but if hex[0] is NUL we have to avoid reading + * past the end of the string: + */ + if (!hex[0]) + return -1; + val = (hexval(hex[0]) << 4) | hexval(hex[1]); + if (val & ~0xff) + return -1; + *sha1++ = val; + hex += 2; + } + return 0; +} + +int main(int argc, char **argv) +{ + /* oversized so we can read the whole buffer in */ + static unsigned char buf[25 * 1024 * 1024]; + char header[32]; + int header_len; + unsigned char have[20], want[20]; + int start, len; + SHA_CTX orig; + unsigned i, j; + + if (!argv[1] || get_sha1_hex(argv[1], want)) { + fprintf(stderr, "usage: sha1-munge <sha1> [start] <file.in\n"); + return 1; + } + + if (argv[2]) + start = atoi(argv[2]); + else + start = 0; + + len = read(0, buf, sizeof(buf)); + header_len = sprintf(header, "blob %d", len) + 1; + fprintf(stderr, "using header: %s\n", header); + + /* + * We keep a running sha1 so that if you are munging + * near the end of the file, we do not have to re-sha1 + * the unchanged earlier bytes + */ + SHA1_Init(&orig); + SHA1_Update(&orig, header, header_len); + if (start) + SHA1_Update(&orig, buf, start); + + signal(SIGALRM, progress); + alarm(1); + + for (i = start; i < len; i++) { + unsigned char c; + SHA_CTX x; + +#if 0 + /* + * deletion -- this would not actually work in practice, + * I think, because we've already committed to a + * particular size in the header. Ditto for addition + * below. In those cases, you'd have to do the whole + * sha1 from scratch, or possibly keep three running + * "orig" sha1 computations going. + */ + memcpy(&x, &orig, sizeof(x)); + SHA1_Update(&x, buf + i + 1, len - i - 1); + SHA1_Final(have, &x); + if (!memcmp(have, want, 20)) + printf("i=%d, deletion\n", i); +#endif + + /* + * replacement -- note that this tries each of the 256 + * possible bytes. If you suspect a single-bit flip, + * it would be much shorter to just try the 8 + * bit-flipped variants. + */ + c = buf[i]; + for (j = 0; j <= 0xff; j++) { + buf[i] = j; + + memcpy(&x, &orig, sizeof(x)); + SHA1_Update(&x, buf + i, len - i); + SHA1_Final(have, &x); + if (!memcmp(have, want, 20)) + printf("i=%d, j=%02x\n", i, j); + } + buf[i] = c; + +#if 0 + /* addition */ + for (j = 0; j <= 0xff; j++) { + unsigned char extra = j; + memcpy(&x, &orig, sizeof(x)); + SHA1_Update(&x, &extra, 1); + SHA1_Update(&x, buf + i, len - i); + SHA1_Final(have, &x); + if (!memcmp(have, want, 20)) + printf("i=%d, addition=%02x", i, j); + } +#endif + + SHA1_Update(&orig, buf + i, 1); + counter++; + } + + alarm(0); + fprintf(stderr, "\r%d\n", counter); + return 0; +} +-------------------------- diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index b87784d..dcf7429 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -115,19 +115,22 @@ The placeholders are: - '%aD': author date, RFC2822 style - '%ar': author date, relative - '%at': author date, UNIX timestamp -- '%ai': author date, ISO 8601 format +- '%ai': author date, ISO 8601-like format +- '%aI': author date, strict ISO 8601 format - '%cn': committer name - '%cN': committer name (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1]) - '%ce': committer email - '%cE': committer email (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1]) -- '%cd': committer date +- '%cd': committer date (format respects --date= option) - '%cD': committer date, RFC2822 style - '%cr': committer date, relative - '%ct': committer date, UNIX timestamp -- '%ci': committer date, ISO 8601 format +- '%ci': committer date, ISO 8601-like format +- '%cI': committer date, strict ISO 8601 format - '%d': ref names, like the --decorate option of linkgit:git-log[1] +- '%D': ref names without the " (", ")" wrapping. - '%e': encoding - '%s': subject - '%f': sanitized subject line, suitable for a filename @@ -182,8 +185,9 @@ The placeholders are: NOTE: Some placeholders may depend on other options given to the revision traversal engine. For example, the `%g*` reflog options will insert an empty string unless we are traversing reflog entries (e.g., by -`git log -g`). The `%d` placeholder will use the "short" decoration -format if `--decorate` was not already provided on the command line. +`git log -g`). The `%d` and `%D` placeholders will use the "short" +decoration format if `--decorate` was not already provided on the command +line. If you add a `+` (plus sign) after '%' of a placeholder, a line-feed is inserted immediately before the expansion if and only if the diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index deb8cca..97ef2e8 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -160,7 +160,7 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit). consider. Repetitions of this option accumulate exclusion patterns up to the next `--all`, `--branches`, `--tags`, `--remotes`, or `--glob` option (other options or arguments do not clear - accumlated patterns). + accumulated patterns). + The patterns given should not begin with `refs/heads`, `refs/tags`, or `refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`, @@ -168,6 +168,10 @@ respectively, and they must begin with `refs/` when applied to `--glob` or `--all`. If a trailing '/{asterisk}' is intended, it must be given explicitly. +--reflog:: + Pretend as if all objects mentioned by reflogs are listed on the + command line as `<commit>`. + --ignore-missing:: Upon seeing an invalid object name in the input, pretend as if the bad input was not given. @@ -635,6 +639,7 @@ Object Traversal These options are mostly targeted for packing of Git repositories. +ifdef::git-rev-list[] --objects:: Print the object IDs of any object referenced by the listed commits. `--objects foo ^bar` thus means ``send me @@ -644,13 +649,24 @@ These options are mostly targeted for packing of Git repositories. --objects-edge:: Similar to `--objects`, but also print the IDs of excluded commits prefixed with a ``-'' character. This is used by - linkgit:git-pack-objects[1] to build ``thin'' pack, which records + linkgit:git-pack-objects[1] to build a ``thin'' pack, which records objects in deltified form based on objects contained in these excluded commits to reduce network traffic. +--objects-edge-aggressive:: + Similar to `--objects-edge`, but it tries harder to find excluded + commits at the cost of increased time. This is used instead of + `--objects-edge` to build ``thin'' packs for shallow repositories. + +--indexed-objects:: + Pretend as if all trees and blobs used by the index are listed + on the command line. Note that you probably want to use + `--objects`, too. + --unpacked:: Only useful with `--objects`; print the object IDs that are not in packs. +endif::git-rev-list[] --no-walk[=(sorted|unsorted)]:: Only show the given commits, but do not traverse their ancestors. @@ -677,7 +693,7 @@ include::pretty-options.txt[] --relative-date:: Synonym for `--date=relative`. ---date=(relative|local|default|iso|rfc|short|raw):: +--date=(relative|local|default|iso|iso-strict|rfc|short|raw):: Only takes effect for dates shown in human-readable format, such as when using `--pretty`. `log.date` config variable sets a default value for the log command's `--date` option. @@ -687,7 +703,16 @@ e.g. ``2 hours ago''. + `--date=local` shows timestamps in user's local time zone. + -`--date=iso` (or `--date=iso8601`) shows timestamps in ISO 8601 format. +`--date=iso` (or `--date=iso8601`) shows timestamps in a ISO 8601-like format. +The differences to the strict ISO 8601 format are: + + - a space instead of the `T` date/time delimiter + - a space between time and time zone + - no colon between hours and minutes of the time zone + ++ +`--date=iso-strict` (or `--date=iso8601-strict`) shows timestamps in strict +ISO 8601 format. + `--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822 format, often found in email messages. diff --git a/Documentation/technical/api-allocation-growing.txt b/Documentation/technical/api-allocation-growing.txt index 542946b..5a59b54 100644 --- a/Documentation/technical/api-allocation-growing.txt +++ b/Documentation/technical/api-allocation-growing.txt @@ -34,3 +34,6 @@ item[nr++] = value you like; ------------ You are responsible for updating the `nr` variable. + +If you need to specify the number of elements to allocate explicitly +then use the macro `REALLOC_ARRAY(item, alloc)` instead of `ALLOC_GROW`. diff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt index edd5018..0d8b99b 100644 --- a/Documentation/technical/api-config.txt +++ b/Documentation/technical/api-config.txt @@ -77,6 +77,99 @@ To read a specific file in git-config format, use `git_config_from_file`. This takes the same callback and data parameters as `git_config`. +Querying For Specific Variables +------------------------------- + +For programs wanting to query for specific variables in a non-callback +manner, the config API provides two functions `git_config_get_value` +and `git_config_get_value_multi`. They both read values from an internal +cache generated previously from reading the config files. + +`int git_config_get_value(const char *key, const char **value)`:: + + Finds the highest-priority value for the configuration variable `key`, + stores the pointer to it in `value` and returns 0. When the + configuration variable `key` is not found, returns 1 without touching + `value`. The caller should not free or modify `value`, as it is owned + by the cache. + +`const struct string_list *git_config_get_value_multi(const char *key)`:: + + Finds and returns the value list, sorted in order of increasing priority + for the configuration variable `key`. When the configuration variable + `key` is not found, returns NULL. The caller should not free or modify + the returned pointer, as it is owned by the cache. + +`void git_config_clear(void)`:: + + Resets and invalidates the config cache. + +The config API also provides type specific API functions which do conversion +as well as retrieval for the queried variable, including: + +`int git_config_get_int(const char *key, int *dest)`:: + + Finds and parses the value to an integer for the configuration variable + `key`. Dies on error; otherwise, stores the value of the parsed integer in + `dest` and returns 0. When the configuration variable `key` is not found, + returns 1 without touching `dest`. + +`int git_config_get_ulong(const char *key, unsigned long *dest)`:: + + Similar to `git_config_get_int` but for unsigned longs. + +`int git_config_get_bool(const char *key, int *dest)`:: + + Finds and parses the value into a boolean value, for the configuration + variable `key` respecting keywords like "true" and "false". Integer + values are converted into true/false values (when they are non-zero or + zero, respectively). Other values cause a die(). If parsing is successful, + stores the value of the parsed result in `dest` and returns 0. When the + configuration variable `key` is not found, returns 1 without touching + `dest`. + +`int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest)`:: + + Similar to `git_config_get_bool`, except that integers are copied as-is, + and `is_bool` flag is unset. + +`int git_config_get_maybe_bool(const char *key, int *dest)`:: + + Similar to `git_config_get_bool`, except that it returns -1 on error + rather than dying. + +`int git_config_get_string_const(const char *key, const char **dest)`:: + + Allocates and copies the retrieved string into the `dest` parameter for + the configuration variable `key`; if NULL string is given, prints an + error message and returns -1. When the configuration variable `key` is + not found, returns 1 without touching `dest`. + +`int git_config_get_string(const char *key, char **dest)`:: + + Similar to `git_config_get_string_const`, except that retrieved value + copied into the `dest` parameter is a mutable string. + +`int git_config_get_pathname(const char *key, const char **dest)`:: + + Similar to `git_config_get_string`, but expands `~` or `~user` into + the user's home directory when found at the beginning of the path. + +`git_die_config(const char *key, const char *err, ...)`:: + + First prints the error message specified by the caller in `err` and then + dies printing the line number and the file name of the highest priority + value for the configuration variable `key`. + +`void git_die_config_linenr(const char *key, const char *filename, int linenr)`:: + + Helper function which formats the die error message according to the + parameters entered. Used by `git_die_config()`. It can be used by callers + handling `git_config_get_value_multi()` to print the correct error message + for the desired value. + +See test-config.c for usage examples. + Value Parsing Helpers --------------------- @@ -134,6 +227,68 @@ int read_file_with_include(const char *file, config_fn_t fn, void *data) `git_config` respects includes automatically. The lower-level `git_config_from_file` does not. +Custom Configsets +----------------- + +A `config_set` can be used to construct an in-memory cache for +config-like files that the caller specifies (i.e., files like `.gitmodules`, +`~/.gitconfig` etc.). For example, + +--------------------------------------- +struct config_set gm_config; +git_configset_init(&gm_config); +int b; +/* we add config files to the config_set */ +git_configset_add_file(&gm_config, ".gitmodules"); +git_configset_add_file(&gm_config, ".gitmodules_alt"); + +if (!git_configset_get_bool(gm_config, "submodule.frotz.ignore", &b)) { + /* hack hack hack */ +} + +/* when we are done with the configset */ +git_configset_clear(&gm_config); +---------------------------------------- + +Configset API provides functions for the above mentioned work flow, including: + +`void git_configset_init(struct config_set *cs)`:: + + Initializes the config_set `cs`. + +`int git_configset_add_file(struct config_set *cs, const char *filename)`:: + + Parses the file and adds the variable-value pairs to the `config_set`, + dies if there is an error in parsing the file. Returns 0 on success, or + -1 if the file does not exist or is inaccessible. The user has to decide + if he wants to free the incomplete configset or continue using it when + the function returns -1. + +`int git_configset_get_value(struct config_set *cs, const char *key, const char **value)`:: + + Finds the highest-priority value for the configuration variable `key` + and config set `cs`, stores the pointer to it in `value` and returns 0. + When the configuration variable `key` is not found, returns 1 without + touching `value`. The caller should not free or modify `value`, as it + is owned by the cache. + +`const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key)`:: + + Finds and returns the value list, sorted in order of increasing priority + for the configuration variable `key` and config set `cs`. When the + configuration variable `key` is not found, returns NULL. The caller + should not free or modify the returned pointer, as it is owned by the cache. + +`void git_configset_clear(struct config_set *cs)`:: + + Clears `config_set` structure, removes all saved variable-value pairs. + +In addition to above functions, the `config_set` API provides type specific +functions in the vein of `git_config_get_int` and family but with an extra +parameter, pointer to struct `config_set`. +They all behave similarly to the `git_config_get*()` family described in +"Querying For Specific Variables" above. + Writing Config Files -------------------- diff --git a/Documentation/technical/api-credentials.txt b/Documentation/technical/api-credentials.txt index c1b42a4..e44426d 100644 --- a/Documentation/technical/api-credentials.txt +++ b/Documentation/technical/api-credentials.txt @@ -248,7 +248,10 @@ FORMAT` in linkgit:git-credential[7] for a detailed specification). For a `get` operation, the helper should produce a list of attributes on stdout in the same format. A helper is free to produce a subset, or even no values at all if it has nothing useful to provide. Any provided -attributes will overwrite those already known about by Git. +attributes will overwrite those already known about by Git. If a helper +outputs a `quit` attribute with a value of `true` or `1`, no further +helpers will be consulted, nor will the user be prompted (if no +credential has been provided, the operation will then fail). For a `store` or `erase` operation, the helper's output is ignored. If it fails to perform the requested operation, it may complain to diff --git a/Documentation/technical/api-lockfile.txt b/Documentation/technical/api-lockfile.txt index dd89404..93b5f23 100644 --- a/Documentation/technical/api-lockfile.txt +++ b/Documentation/technical/api-lockfile.txt @@ -3,20 +3,132 @@ lockfile API The lockfile API serves two purposes: -* Mutual exclusion. When we write out a new index file, first - we create a new file `$GIT_DIR/index.lock`, write the new - contents into it, and rename it to the final destination - `$GIT_DIR/index`. We try to create the `$GIT_DIR/index.lock` - file with O_EXCL so that we can notice and fail when somebody - else is already trying to update the index file. - -* Automatic cruft removal. After we create the "lock" file, we - may decide to `die()`, and we would want to make sure that we - remove the file that has not been committed to its final - destination. This is done by remembering the lockfiles we - created in a linked list and cleaning them up from an - `atexit(3)` handler. Outstanding lockfiles are also removed - when the program dies on a signal. +* Mutual exclusion and atomic file updates. When we want to change a + file, we create a lockfile `<filename>.lock`, write the new file + contents into it, and then rename the lockfile to its final + destination `<filename>`. We create the `<filename>.lock` file with + `O_CREAT|O_EXCL` so that we can notice and fail if somebody else has + already locked the file, then atomically rename the lockfile to its + final destination to commit the changes and unlock the file. + +* Automatic cruft removal. If the program exits after we lock a file + but before the changes have been committed, we want to make sure + that we remove the lockfile. This is done by remembering the + lockfiles we have created in a linked list and setting up an + `atexit(3)` handler and a signal handler that clean up the + lockfiles. This mechanism ensures that outstanding lockfiles are + cleaned up if the program exits (including when `die()` is called) + or if the program dies on a signal. + +Please note that lockfiles only block other writers. Readers do not +block, but they are guaranteed to see either the old contents of the +file or the new contents of the file (assuming that the filesystem +implements `rename(2)` atomically). + + +Calling sequence +---------------- + +The caller: + +* Allocates a `struct lock_file` either as a static variable or on the + heap, initialized to zeros. Once you use the structure to call the + `hold_lock_file_*` family of functions, it belongs to the lockfile + subsystem and its storage must remain valid throughout the life of + the program (i.e. you cannot use an on-stack variable to hold this + structure). + +* Attempts to create a lockfile by passing that variable and the path + of the final destination (e.g. `$GIT_DIR/index`) to + `hold_lock_file_for_update` or `hold_lock_file_for_append`. + +* Writes new content for the destination file by either: + + * writing to the file descriptor returned by the `hold_lock_file_*` + functions (also available via `lock->fd`). + + * calling `fdopen_lock_file` to get a `FILE` pointer for the open + file and writing to the file using stdio. + +When finished writing, the caller can: + +* Close the file descriptor and rename the lockfile to its final + destination by calling `commit_lock_file` or `commit_lock_file_to`. + +* Close the file descriptor and remove the lockfile by calling + `rollback_lock_file`. + +* Close the file descriptor without removing or renaming the lockfile + by calling `close_lock_file`, and later call `commit_lock_file`, + `commit_lock_file_to`, `rollback_lock_file`, or `reopen_lock_file`. + +Even after the lockfile is committed or rolled back, the `lock_file` +object must not be freed or altered by the caller. However, it may be +reused; just pass it to another call of `hold_lock_file_for_update` or +`hold_lock_file_for_append`. + +If the program exits before you have called one of `commit_lock_file`, +`commit_lock_file_to`, `rollback_lock_file`, or `close_lock_file`, an +`atexit(3)` handler will close and remove the lockfile, rolling back +any uncommitted changes. + +If you need to close the file descriptor you obtained from a +`hold_lock_file_*` function yourself, do so by calling +`close_lock_file`. You should never call `close(2)` or `fclose(3)` +yourself! Otherwise the `struct lock_file` structure would still think +that the file descriptor needs to be closed, and a commit or rollback +would result in duplicate calls to `close(2)`. Worse yet, if you close +and then later open another file descriptor for a completely different +purpose, then a commit or rollback might close that unrelated file +descriptor. + + +Error handling +-------------- + +The `hold_lock_file_*` functions return a file descriptor on success +or -1 on failure (unless `LOCK_DIE_ON_ERROR` is used; see below). On +errors, `errno` describes the reason for failure. Errors can be +reported by passing `errno` to one of the following helper functions: + +unable_to_lock_message:: + + Append an appropriate error message to a `strbuf`. + +unable_to_lock_error:: + + Emit an appropriate error message using `error()`. + +unable_to_lock_die:: + + Emit an appropriate error message and `die()`. + +Similarly, `commit_lock_file`, `commit_lock_file_to`, and +`close_lock_file` return 0 on success. On failure they set `errno` +appropriately, do their best to roll back the lockfile, and return -1. + + +Flags +----- + +The following flags can be passed to `hold_lock_file_for_update` or +`hold_lock_file_for_append`: + +LOCK_NO_DEREF:: + + Usually symbolic links in the destination path are resolved + and the lockfile is created by adding ".lock" to the resolved + path. If `LOCK_NO_DEREF` is set, then the lockfile is created + by adding ".lock" to the path argument itself. This option is + used, for example, when locking a symbolic reference, which + for backwards-compatibility reasons can be a symbolic link + containing the name of the referred-to-reference. + +LOCK_DIE_ON_ERROR:: + + If a lock is already taken for the file, `die()` with an error + message. If this option is not specified, trying to lock a + file that is already locked returns -1 to the caller. The functions @@ -24,51 +136,85 @@ The functions hold_lock_file_for_update:: - Take a pointer to `struct lock_file`, the filename of - the final destination (e.g. `$GIT_DIR/index`) and a flag - `die_on_error`. Attempt to create a lockfile for the - destination and return the file descriptor for writing - to the file. If `die_on_error` flag is true, it dies if - a lock is already taken for the file; otherwise it - returns a negative integer to the caller on failure. + Take a pointer to `struct lock_file`, the path of the file to + be locked (e.g. `$GIT_DIR/index`) and a flags argument (see + above). Attempt to create a lockfile for the destination and + return the file descriptor for writing to the file. + +hold_lock_file_for_append:: + + Like `hold_lock_file_for_update`, but before returning copy + the existing contents of the file (if any) to the lockfile and + position its write pointer at the end of the file. + +fdopen_lock_file:: + + Associate a stdio stream with the lockfile. Return NULL + (*without* rolling back the lockfile) on error. The stream is + closed automatically when `close_lock_file` is called or when + the file is committed or rolled back. + +get_locked_file_path:: + + Return the path of the file that is locked by the specified + lock_file object. The caller must free the memory. commit_lock_file:: - Take a pointer to the `struct lock_file` initialized - with an earlier call to `hold_lock_file_for_update()`, - close the file descriptor and rename the lockfile to its - final destination. Returns 0 upon success, a negative - value on failure to close(2) or rename(2). + Take a pointer to the `struct lock_file` initialized with an + earlier call to `hold_lock_file_for_update` or + `hold_lock_file_for_append`, close the file descriptor, and + rename the lockfile to its final destination. Return 0 upon + success. On failure, roll back the lock file and return -1, + with `errno` set to the value from the failing call to + `close(2)` or `rename(2)`. It is a bug to call + `commit_lock_file` for a `lock_file` object that is not + currently locked. + +commit_lock_file_to:: + + Like `commit_lock_file()`, except that it takes an explicit + `path` argument to which the lockfile should be renamed. The + `path` must be on the same filesystem as the lock file. rollback_lock_file:: - Take a pointer to the `struct lock_file` initialized - with an earlier call to `hold_lock_file_for_update()`, - close the file descriptor and remove the lockfile. + Take a pointer to the `struct lock_file` initialized with an + earlier call to `hold_lock_file_for_update` or + `hold_lock_file_for_append`, close the file descriptor and + remove the lockfile. It is a NOOP to call + `rollback_lock_file()` for a `lock_file` object that has + already been committed or rolled back. close_lock_file:: - Take a pointer to the `struct lock_file` initialized - with an earlier call to `hold_lock_file_for_update()`, - and close the file descriptor. Returns 0 upon success, - a negative value on failure to close(2). - -Because the structure is used in an `atexit(3)` handler, its -storage has to stay throughout the life of the program. It -cannot be an auto variable allocated on the stack. - -Call `commit_lock_file()` or `rollback_lock_file()` when you are -done writing to the file descriptor. If you do not call either -and simply `exit(3)` from the program, an `atexit(3)` handler -will close and remove the lockfile. - -If you need to close the file descriptor you obtained from -`hold_lock_file_for_update` function yourself, do so by calling -`close_lock_file()`. You should never call `close(2)` yourself! -Otherwise the `struct -lock_file` structure still remembers that the file descriptor -needs to be closed, and a later call to `commit_lock_file()` or -`rollback_lock_file()` will result in duplicate calls to -`close(2)`. Worse yet, if you `close(2)`, open another file -descriptor for completely different purpose, and then call -`commit_lock_file()` or `rollback_lock_file()`, they may close -that unrelated file descriptor. + + Take a pointer to the `struct lock_file` initialized with an + earlier call to `hold_lock_file_for_update` or + `hold_lock_file_for_append`. Close the file descriptor (and + the file pointer if it has been opened using + `fdopen_lock_file`). Return 0 upon success. On failure to + `close(2)`, return a negative value and roll back the lock + file. Usually `commit_lock_file`, `commit_lock_file_to`, or + `rollback_lock_file` should eventually be called if + `close_lock_file` succeeds. + +reopen_lock_file:: + + Re-open a lockfile that has been closed (using + `close_lock_file`) but not yet committed or rolled back. This + can be used to implement a sequence of operations like the + following: + + * Lock file. + + * Write new contents to lockfile, then `close_lock_file` to + cause the contents to be written to disk. + + * Pass the name of the lockfile to another program to allow it + (and nobody else) to inspect the contents you wrote, while + still holding the lock yourself. + + * `reopen_lock_file` to reopen the lockfile. Make further + updates to the contents. + + * `commit_lock_file` to make the final version permanent. diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt index 69510ae..a9fdb45 100644 --- a/Documentation/technical/api-run-command.txt +++ b/Documentation/technical/api-run-command.txt @@ -13,6 +13,10 @@ produces in the caller in order to process it. Functions --------- +`child_process_init`:: + + Initialize a struct child_process variable. + `start_command`:: Start a sub-process. Takes a pointer to a `struct child_process` @@ -96,8 +100,8 @@ command to run in a sub-process. The caller: -1. allocates and clears (memset(&chld, 0, sizeof(chld));) a - struct child_process variable; +1. allocates and clears (using child_process_init() or + CHILD_PROCESS_INIT) a struct child_process variable; 2. initializes the members; 3. calls start_command(); 4. processes the data; @@ -165,6 +169,11 @@ string pointers (NULL terminated) in .env: . If the string does not contain '=', it names an environment variable that will be removed from the child process's environment. +If the .env member is NULL, `start_command` will point it at the +.env_array `argv_array` (so you may use one or the other, but not both). +The memory in .env_array will be cleaned up automatically during +`finish_command` (or during `start_command` when it is unsuccessful). + To specify a new initial working directory for the sub-process, specify it in the .dir member. diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt index f9c06a7..cca6543 100644 --- a/Documentation/technical/api-strbuf.txt +++ b/Documentation/technical/api-strbuf.txt @@ -160,6 +160,10 @@ then they will free() it. Add a single character to the buffer. +`strbuf_addchars`:: + + Add a character the specified number of times to the buffer. + `strbuf_insert`:: Insert data to the given position of the buffer. The remaining contents @@ -307,6 +311,16 @@ same behaviour as well. use it unless you need the correct position in the file descriptor. +`strbuf_getcwd`:: + + Set the buffer to the path of the current working directory. + +`strbuf_add_absolute_path` + + Add a path to a buffer, converting a relative path to an + absolute one in the process. Symbolic links are not + resolved. + `stripspace`:: Strip whitespace from a buffer. The second parameter controls if diff --git a/Documentation/technical/api-string-list.txt b/Documentation/technical/api-string-list.txt index d51a657..c08402b 100644 --- a/Documentation/technical/api-string-list.txt +++ b/Documentation/technical/api-string-list.txt @@ -29,7 +29,7 @@ member (you need this if you add things later) and you should set the `unsorted_string_list_has_string` and get it from the list using `string_list_lookup` for sorted lists. -. Can sort an unsorted list using `sort_string_list`. +. Can sort an unsorted list using `string_list_sort`. . Can remove duplicate items from a sorted list using `string_list_remove_duplicates`. @@ -146,7 +146,7 @@ write `string_list_insert(...)->util = ...;`. ownership of a malloc()ed string to a `string_list` that has `strdup_string` set. -`sort_string_list`:: +`string_list_sort`:: Sort the list's entries by string value in `strcmp()` order. diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index fe6f316..35112e4 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -207,7 +207,7 @@ Git index format in a separate file. This extension records the changes to be made on top of that to produce the final index. - The signature for this extension is { 'l', 'i, 'n', 'k' }. + The signature for this extension is { 'l', 'i', 'n', 'k' }. The extension consists of: @@ -231,5 +231,5 @@ Git index format on. Replaced entries may have empty path names to save space. The remaining index entries after replaced ones will be added to the - final index. These added entries are also sorted by entry namme then + final index. These added entries are also sorted by entry name then stage. diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 569c48a..462e206 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -212,9 +212,9 @@ out of what the server said it could do with the first 'want' line. want-list = first-want *additional-want - shallow-line = PKT_LINE("shallow" SP obj-id) + shallow-line = PKT-LINE("shallow" SP obj-id) - depth-request = PKT_LINE("deepen" SP depth) + depth-request = PKT-LINE("deepen" SP depth) first-want = PKT-LINE("want" SP obj-id SP capability-list LF) additional-want = PKT-LINE("want" SP obj-id LF) @@ -465,7 +465,7 @@ contain all the objects that the server will need to complete the new references. ---- - update-request = *shallow command-list [pack-file] + update-request = *shallow ( command-list | push-cert ) [pack-file] shallow = PKT-LINE("shallow" SP obj-id LF) @@ -481,12 +481,27 @@ references. old-id = obj-id new-id = obj-id + push-cert = PKT-LINE("push-cert" NUL capability-list LF) + PKT-LINE("certificate version 0.1" LF) + PKT-LINE("pusher" SP ident LF) + PKT-LINE("pushee" SP url LF) + PKT-LINE("nonce" SP nonce LF) + PKT-LINE(LF) + *PKT-LINE(command LF) + *PKT-LINE(gpg-signature-lines LF) + PKT-LINE("push-cert-end" LF) + pack-file = "PACK" 28*(OCTET) ---- If the receiving end does not support delete-refs, the sending end MUST NOT ask for delete command. +If the receiving end does not support push-cert, the sending end +MUST NOT send a push-cert command. When a push-cert command is +sent, command-list MUST NOT be sent; the commands recorded in the +push certificate is used instead. + The pack-file MUST NOT be sent if the only command used is 'delete'. A pack-file MUST be sent if either create or update command is used, @@ -501,6 +516,34 @@ was being processed (the obj-id is still the same as the old-id), and it will run any update hooks to make sure that the update is acceptable. If all of that is fine, the server will then update the references. +Push Certificate +---------------- + +A push certificate begins with a set of header lines. After the +header and an empty line, the protocol commands follow, one per +line. + +Currently, the following header fields are defined: + +`pusher` ident:: + Identify the GPG key in "Human Readable Name <email@address>" + format. + +`pushee` url:: + The repository URL (anonymized, if the URL contains + authentication material) the user who ran `git push` + intended to push into. + +`nonce` nonce:: + The 'nonce' string the receiving repository asked the + pushing user to include in the certificate, to prevent + replay attacks. + +The GPG signature lines are a detached signature for the contents +recorded in the push certificate before the signature block begins. +The detached signature is used to certify that the commands were +given by the pusher, who must be the signer. + Report Status ------------- diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index e174343..6d5424c 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -18,8 +18,8 @@ was sent. Server MUST NOT ignore capabilities that client requested and server advertised. As a consequence of these rules, server MUST NOT advertise capabilities it does not understand. -The 'report-status', 'delete-refs', and 'quiet' capabilities are sent and -recognized by the receive-pack (push to server) process. +The 'report-status', 'delete-refs', 'quiet', and 'push-cert' capabilities +are sent and recognized by the receive-pack (push to server) process. The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized by both upload-pack and receive-pack protocols. The 'agent' capability @@ -168,7 +168,7 @@ agent capability). The `X` and `Y` strings may contain any printable ASCII characters except space (i.e., the byte range 32 < x < 127), and are typically of the form "package/version" (e.g., "git/1.8.3.1"). The agent strings are purely informative for statistics and debugging -purposes, and MUST NOT be used to programatically assume the presence +purposes, and MUST NOT be used to programmatically assume the presence or absence of particular features. shallow @@ -250,3 +250,12 @@ allow-tip-sha1-in-want If the upload-pack server advertises this capability, fetch-pack may send "want" lines with SHA-1s that exist at the server but are not advertised by upload-pack. + +push-cert=<nonce> +----------------- + +The receive-pack server that advertises this capability is willing +to accept a signed push certificate, and asks the <nonce> to be +included in the push certificate. A send-pack client MUST NOT +send a push-cert packet unless the receive-pack server advertises +this capability. |