From 5f95c9f850b19b368c43ae399cc831b17a26a5ac Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 14 Feb 2014 11:35:04 -0800 Subject: Git 1.9.0 Signed-off-by: Junio C Hamano --- Documentation/RelNotes/1.9.0.txt | 345 ++++++++++++++++++++++++++++++++++++ Documentation/RelNotes/1.9.txt | 372 --------------------------------------- Documentation/git.txt | 5 + GIT-VERSION-GEN | 2 +- RelNotes | 2 +- 5 files changed, 352 insertions(+), 374 deletions(-) create mode 100644 Documentation/RelNotes/1.9.0.txt delete mode 100644 Documentation/RelNotes/1.9.txt diff --git a/Documentation/RelNotes/1.9.0.txt b/Documentation/RelNotes/1.9.0.txt new file mode 100644 index 000000000..752d79127 --- /dev/null +++ b/Documentation/RelNotes/1.9.0.txt @@ -0,0 +1,345 @@ +Git v1.9.0 Release Notes +======================== + +Backward compatibility notes +---------------------------- + +"git submodule foreach $cmd $args" used to treat "$cmd $args" the same +way "ssh" did, concatenating them into a single string and letting the +shell unquote. Careless users who forget to sufficiently quote $args +get their argument split at $IFS whitespaces by the shell, and got +unexpected results due to this. Starting from this release, the +command line is passed directly to the shell, if it has an argument. + +Read-only support for experimental loose-object format, in which users +could optionally choose to write their loose objects for a short +while between v1.4.3 and v1.5.3 era, has been dropped. + +The meanings of the "--tags" option to "git fetch" has changed; the +command fetches tags _in addition to_ what is fetched by the same +command line without the option. + +The way "git push $there $what" interprets the $what part given on the +command line, when it does not have a colon that explicitly tells us +what ref at the $there repository is to be updated, has been enhanced. + +A handful of ancient commands that have long been deprecated are +finally gone (repo-config, tar-tree, lost-found, and peek-remote). + + +Backward compatibility notes (for Git 2.0.0) +-------------------------------------------- + +When "git push [$there]" does not say what to push, we have used the +traditional "matching" semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). In Git 2.0, the default will change to the "simple" +semantics, which pushes: + + - only the current branch to the branch with the same name, and only + when the current branch is set to integrate with that remote + branch, if you are pushing to the same remote as you fetch from; or + + - only the current branch to the branch with the same name, if you + are pushing to a remote that is not where you usually fetch from. + +Use the user preference configuration variable "push.default" to +change this. If you are an old-timer who is used to the "matching" +semantics, you can set the variable to "matching" to keep the +traditional behaviour. If you want to live in the future early, you +can set it to "simple" today without waiting for Git 2.0. + +When "git add -u" (and "git add -A") is run inside a subdirectory and +does not specify which paths to add on the command line, it +will operate on the entire tree in Git 2.0 for consistency +with "git commit -a" and other commands. There will be no +mechanism to make plain "git add -u" behave like "git add -u .". +Current users of "git add -u" (without a pathspec) should start +training their fingers to explicitly say "git add -u ." +before Git 2.0 comes. A warning is issued when these commands are +run without a pathspec and when you have local changes outside the +current directory, because the behaviour in Git 2.0 will be different +from today's version in such a situation. + +In Git 2.0, "git add " will behave as "git add -A ", so +that "git add dir/" will notice paths you removed from the directory +and record the removal. Versions before Git 2.0, including this +release, will keep ignoring removals, but the users who rely on this +behaviour are encouraged to start using "git add --ignore-removal " +now before 2.0 is released. + +The default prefix for "git svn" will change in Git 2.0. For a long +time, "git svn" created its remote-tracking branches directly under +refs/remotes, but it will place them under refs/remotes/origin/ unless +it is told otherwise with its --prefix option. + + +Updates since v1.8.5 +-------------------- + +Foreign interfaces, subsystems and ports. + + * The HTTP transport, when talking GSS-Negotiate, uses "100 + Continue" response to avoid having to rewind and resend a large + payload, which may not be always doable. + + * Various bugfixes to remote-bzr and remote-hg (in contrib/). + + * The build procedure is aware of MirBSD now. + + * Various "git p4", "git svn" and "gitk" updates. + + +UI, Workflows & Features + + * Fetching from a shallowly-cloned repository used to be forbidden, + primarily because the codepaths involved were not carefully vetted + and we did not bother supporting such usage. This release attempts + to allow object transfer out of a shallowly-cloned repository in a + more controlled way (i.e. the receiver becomes a shallow repository + with a truncated history). + + * Just like we give a reasonable default for "less" via the LESS + environment variable, we now specify a reasonable default for "lv" + via the "LV" environment variable when spawning the pager. + + * Two-level configuration variable names in "branch.*" and "remote.*" + hierarchies, whose variables are predominantly three-level, were + not completed by hitting a in bash and zsh completions. + + * Fetching a 'frotz' branch with "git fetch", while a 'frotz/nitfol' + remote-tracking branch from an earlier fetch was still there, would + error out, primarily because the command was not told that it is + allowed to lose any information on our side. "git fetch --prune" + now can be used to remove 'frotz/nitfol' to make room for fetching and + storing the 'frotz' remote-tracking branch. + + * "diff.orderfile=" configuration variable can be used to + pretend as if the "-O" option were given from the command + line of "git diff", etc. + + * The negative pathspec syntax allows "git log -- . ':!dir'" to tell + us "I am interested in everything but 'dir' directory". + + * "git difftool" shows how many different paths there are in total, + and how many of them have been shown so far, to indicate progress. + + * "git push origin master" used to push our 'master' branch to update + the 'master' branch at the 'origin' repository. This has been + enhanced to use the same ref mapping "git push origin" would use to + determine what ref at the 'origin' to be updated with our 'master'. + For example, with this configuration + + [remote "origin"] + push = refs/heads/*:refs/review/* + + that would cause "git push origin" to push out our local branches + to corresponding refs under refs/review/ hierarchy at 'origin', + "git push origin master" would update 'refs/review/master' over + there. Alternatively, if push.default is set to 'upstream' and our + 'master' is set to integrate with 'topic' from the 'origin' branch, + running "git push origin" while on our 'master' would update their + 'topic' branch, and running "git push origin master" while on any + of our branches does the same. + + * "gitweb" learned to treat ref hierarchies other than refs/heads as + if they are additional branch namespaces (e.g. refs/changes/ in + Gerrit). + + * "git for-each-ref --format=..." learned a few formatting directives; + e.g. "%(color:red)%(HEAD)%(color:reset) %(refname:short) %(subject)". + + * The command string given to "git submodule foreach" is passed + directly to the shell, without being eval'ed. This is a backward + incompatible change that may break existing users. + + * "git log" and friends learned the "--exclude=" option, to + allow people to say "list history of all branches except those that + match this pattern" with "git log --exclude='*/*' --branches". + + * "git rev-parse --parseopt" learned a new "--stuck-long" option to + help scripts parse options with an optional parameter. + + * The "--tags" option to "git fetch" no longer tells the command to + fetch _only_ the tags. It instead fetches tags _in addition to_ + what are fetched by the same command line without the option. + + +Performance, Internal Implementation, etc. + + * When parsing a 40-hex string into the object name, the string is + checked to see if it can be interpreted as a ref so that a warning + can be given for ambiguity. The code kicked in even when the + core.warnambiguousrefs is set to false to squelch this warning, in + which case the cycles spent to look at the ref namespace were an + expensive no-op, as the result was discarded without being used. + + * The naming convention of the packfiles has been updated; it used to + be based on the enumeration of names of the objects that are + contained in the pack, but now it also depends on how the packed + result is represented---packing the same set of objects using + different settings (or delta order) would produce a pack with + different name. + + * "git diff --no-index" mode used to unnecessarily attempt to read + the index when there is one. + + * The deprecated parse-options macro OPT_BOOLEAN has been removed; + use OPT_BOOL or OPT_COUNTUP in new code. + + * A few duplicate implementations of prefix/suffix string comparison + functions have been unified to starts_with() and ends_with(). + + * The new PERLLIB_EXTRA makefile variable can be used to specify + additional directories Perl modules (e.g. the ones necessary to run + git-svn) are installed on the platform when building. + + * "git merge-base" learned the "--fork-point" mode, that implements + the same logic used in "git pull --rebase" to find a suitable fork + point out of the reflog entries for the remote-tracking branch the + work has been based on. "git rebase" has the same logic that can be + triggered with the "--fork-point" option. + + * A third-party "receive-pack" (the responder to "git push") can + advertise the "no-thin" capability to tell "git push" not to use + the thin-pack optimization. Our receive-pack has always been + capable of accepting and fattening a thin-pack, and will continue + not to ask "git push" to use a non-thin pack. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v1.8.5 +------------------ + +Unless otherwise noted, all the fixes since v1.8.5 in the maintenance +track are contained in this release (see the maintenance releases' notes +for details). + + * The pathspec matching code, while comparing two trees (e.g. "git + diff A B -- path1 path2") was too aggressive and failed to match + some paths when multiple pathspecs were involved. + + * "git repack --max-pack-size=8g" stopped being parsed correctly when + the command was reimplemented in C. + + * An earlier update in v1.8.4.x to "git rev-list --objects" with + negative ref had a performance regression. + (merge 200abe7 jk/mark-edges-uninteresting later to maint). + + * A recent update to "git send-email" broke platforms where + /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path + (e.g. Fedora rawhide). + + * A handful of bugs around interpreting $branch@{upstream} notation + and its lookalike, when $branch part has interesting characters, + e.g. "@", and ":", have been fixed. + + * "git clone" would fail to clone from a repository that has a ref + directly under "refs/", e.g. "refs/stash", because different + validation paths do different things on such a refname. Loosen the + client side's validation to allow such a ref. + + * "git log --left-right A...B" lost the "leftness" of commits + reachable from A when A is a tag as a side effect of a recent + bugfix. This is a regression in 1.8.4.x series. + + * documentations to "git pull" hinted there is an "-m" option because + it incorrectly shared the documentation with "git merge". + + * "git diff A B submod" and "git diff A B submod/" ought to have done + the same for a submodule "submod", but didn't. + + * "git clone $origin foo\bar\baz" on Windows failed to create the + leading directories (i.e. a moral-equivalent of "mkdir -p"). + + * "submodule.*.update=checkout", when propagated from .gitmodules to + .git/config, turned into a "submodule.*.update=none", which did not + make much sense. + (merge efa8fd7 fp/submodule-checkout-mode later to maint). + + * The implementation of 'git stash $cmd "stash@{...}"' did not quote + the stash argument properly and left it split at IFS whitespace. + + * The "--[no-]informative-errors" options to "git daemon" were parsed + a bit too loosely, allowing any other string after these option + names. + + * There is no reason to have a hardcoded upper limit for the number of + parents of an octopus merge, created via the graft mechanism, but + there was. + + * The basic test used to leave unnecessary trash directories in the + t/ directory. + (merge 738a8be jk/test-framework-updates later to maint). + + * "git merge-base --octopus" used to leave cleaning up suboptimal + result to the caller, but now it does the clean-up itself. + + * A "gc" process running as a different user should be able to stop a + new "gc" process from starting, but it didn't. + + * An earlier "clean-up" introduced an unnecessary memory leak. + + * "git add -A" (no other arguments) in a totally empty working tree + used to emit an error. + + * "git log --decorate" did not handle a tag pointed by another tag + nicely. + + * When we figure out how many file descriptors to allocate for + keeping packfiles open, a system with non-working getrlimit() could + cause us to die(), but because we make this call only to get a + rough estimate of how many are available and we do not even attempt + to use up all available file descriptors ourselves, it is nicer to + fall back to a reasonable low value rather than dying. + + * read_sha1_file(), that is the workhorse to read the contents given + an object name, honoured object replacements, but there was no + corresponding mechanism to sha1_object_info() that was used to + obtain the metainfo (e.g. type & size) about the object. This led + callers to weird inconsistencies. + (merge 663a856 cc/replace-object-info later to maint). + + * "git cat-file --batch=", an admittedly useless command, did not + behave very well. + + * "git rev-parse -- " did not implement the usual + disambiguation rules the commands in the "git log" family used in + the same way. + + * "git mv A B/", when B does not exist as a directory, should error + out, but it didn't. + + * A workaround to an old bug in glibc prior to glibc 2.17 has been + retired; this would remove a side effect of the workaround that + corrupts system error messages in non-C locales. + + * SSL-related options were not passed correctly to underlying socket + layer in "git send-email". + + * "git commit -v" appends the patch to the log message before + editing, and then removes the patch when the editor returned + control. However, the patch was not stripped correctly when the + first modified path was a submodule. + + * "git fetch --depth=0" was a no-op, and was silently ignored. + Diagnose it as an error. + + * Remote repository URLs expressed in scp-style host:path notation are + parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks + to connect to user's home directory on host at address ::1. + + * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the + command line parser. + + * "git cat-file --batch-check=ok" did not check the existence of + the named object. + + * "git am --abort" sometimes complained about not being able to write + a tree with an 0{40} object in it. + + * Two processes creating loose objects at the same time could have + failed unnecessarily when the name of their new objects started + with the same byte value, due to a race condition. diff --git a/Documentation/RelNotes/1.9.txt b/Documentation/RelNotes/1.9.txt deleted file mode 100644 index a0cabcd5e..000000000 --- a/Documentation/RelNotes/1.9.txt +++ /dev/null @@ -1,372 +0,0 @@ -Git v1.9 Release Notes -====================== - -Backward compatibility notes ----------------------------- - -"git submodule foreach $cmd $args" used to treat "$cmd $args" the same -way "ssh" did, concatenating them into a single string and letting the -shell unquote. Careless users who forget to sufficiently quote $args -get their argument split at $IFS whitespaces by the shell, and got -unexpected results due to this. Starting from this release, the -command line is passed directly to the shell, if it has an argument. - -Read-only support for experimental loose-object format, in which users -could optionally choose to write their loose objects for a short -while between v1.4.3 and v1.5.3 era, has been dropped. - -The meanings of the "--tags" option to "git fetch" has changed; the -command fetches tags _in addition to_ what is fetched by the same -command line without the option. - -The way "git push $there $what" interprets the $what part given on the -command line, when it does not have a colon that explicitly tells us -what ref at the $there repository is to be updated, has been enhanced. - -A handful of ancient commands that have long been deprecated are -finally gone (repo-config, tar-tree, lost-found, and peek-remote). - - -Backward compatibility notes (for Git 2.0) ------------------------------------------- - -When "git push [$there]" does not say what to push, we have used the -traditional "matching" semantics so far (all your branches were sent -to the remote as long as there already are branches of the same name -over there). In Git 2.0, the default will change to the "simple" -semantics, which pushes: - - - only the current branch to the branch with the same name, and only - when the current branch is set to integrate with that remote - branch, if you are pushing to the same remote as you fetch from; or - - - only the current branch to the branch with the same name, if you - are pushing to a remote that is not where you usually fetch from. - -Use the user preference configuration variable "push.default" to -change this. If you are an old-timer who is used to the "matching" -semantics, you can set the variable to "matching" to keep the -traditional behaviour. If you want to live in the future early, you -can set it to "simple" today without waiting for Git 2.0. - -When "git add -u" (and "git add -A") is run inside a subdirectory and -does not specify which paths to add on the command line, it -will operate on the entire tree in Git 2.0 for consistency -with "git commit -a" and other commands. There will be no -mechanism to make plain "git add -u" behave like "git add -u .". -Current users of "git add -u" (without a pathspec) should start -training their fingers to explicitly say "git add -u ." -before Git 2.0 comes. A warning is issued when these commands are -run without a pathspec and when you have local changes outside the -current directory, because the behaviour in Git 2.0 will be different -from today's version in such a situation. - -In Git 2.0, "git add " will behave as "git add -A ", so -that "git add dir/" will notice paths you removed from the directory -and record the removal. Versions before Git 2.0, including this -release, will keep ignoring removals, but the users who rely on this -behaviour are encouraged to start using "git add --ignore-removal " -now before 2.0 is released. - -The default prefix for "git svn" will change in Git 2.0. For a long -time, "git svn" created its remote-tracking branches directly under -refs/remotes, but it will place them under refs/remotes/origin/ unless -it is told otherwise with its --prefix option. - - -Updates since v1.8.5 --------------------- - -Foreign interfaces, subsystems and ports. - - * The HTTP transport, when talking GSS-Negotiate, uses "100 - Continue" response to avoid having to rewind and resend a large - payload, which may not be always doable. - - * Various bugfixes to remote-bzr and remote-hg (in contrib/). - - * The build procedure is aware of MirBSD now. - - * Various "git p4", "git svn" and "gitk" updates. - - -UI, Workflows & Features - - * Fetching from a shallowly-cloned repository used to be forbidden, - primarily because the codepaths involved were not carefully vetted - and we did not bother supporting such usage. This release attempts - to allow object transfer out of a shallowly-cloned repository in a - more controlled way (i.e. the receiver becomes a shallow repository - with a truncated history). - - * Just like we give a reasonable default for "less" via the LESS - environment variable, we now specify a reasonable default for "lv" - via the "LV" environment variable when spawning the pager. - - * Two-level configuration variable names in "branch.*" and "remote.*" - hierarchies, whose variables are predominantly three-level, were - not completed by hitting a in bash and zsh completions. - - * Fetching a 'frotz' branch with "git fetch", while a 'frotz/nitfol' - remote-tracking branch from an earlier fetch was still there, would - error out, primarily because the command was not told that it is - allowed to lose any information on our side. "git fetch --prune" - now can be used to remove 'frotz/nitfol' to make room for fetching and - storing the 'frotz' remote-tracking branch. - - * "diff.orderfile=" configuration variable can be used to - pretend as if the "-O" option were given from the command - line of "git diff", etc. - - * The negative pathspec syntax allows "git log -- . ':!dir'" to tell - us "I am interested in everything but 'dir' directory". - - * "git difftool" shows how many different paths there are in total, - and how many of them have been shown so far, to indicate progress. - - * "git push origin master" used to push our 'master' branch to update - the 'master' branch at the 'origin' repository. This has been - enhanced to use the same ref mapping "git push origin" would use to - determine what ref at the 'origin' to be updated with our 'master'. - For example, with this configuration - - [remote "origin"] - push = refs/heads/*:refs/review/* - - that would cause "git push origin" to push out our local branches - to corresponding refs under refs/review/ hierarchy at 'origin', - "git push origin master" would update 'refs/review/master' over - there. Alternatively, if push.default is set to 'upstream' and our - 'master' is set to integrate with 'topic' from the 'origin' branch, - running "git push origin" while on our 'master' would update their - 'topic' branch, and running "git push origin master" while on any - of our branches does the same. - - * "gitweb" learned to treat ref hierarchies other than refs/heads as - if they are additional branch namespaces (e.g. refs/changes/ in - Gerrit). - - * "git for-each-ref --format=..." learned a few formatting directives; - e.g. "%(color:red)%(HEAD)%(color:reset) %(refname:short) %(subject)". - - * The command string given to "git submodule foreach" is passed - directly to the shell, without being eval'ed. This is a backward - incompatible change that may break existing users. - - * "git log" and friends learned the "--exclude=" option, to - allow people to say "list history of all branches except those that - match this pattern" with "git log --exclude='*/*' --branches". - - * "git rev-parse --parseopt" learned a new "--stuck-long" option to - help scripts parse options with an optional parameter. - - * The "--tags" option to "git fetch" no longer tells the command to - fetch _only_ the tags. It instead fetches tags _in addition to_ - what are fetched by the same command line without the option. - - -Performance, Internal Implementation, etc. - - * When parsing a 40-hex string into the object name, the string is - checked to see if it can be interpreted as a ref so that a warning - can be given for ambiguity. The code kicked in even when the - core.warnambiguousrefs is set to false to squelch this warning, in - which case the cycles spent to look at the ref namespace were an - expensive no-op, as the result was discarded without being used. - - * The naming convention of the packfiles has been updated; it used to - be based on the enumeration of names of the objects that are - contained in the pack, but now it also depends on how the packed - result is represented---packing the same set of objects using - different settings (or delta order) would produce a pack with - different name. - - * "git diff --no-index" mode used to unnecessarily attempt to read - the index when there is one. - - * The deprecated parse-options macro OPT_BOOLEAN has been removed; - use OPT_BOOL or OPT_COUNTUP in new code. - - * A few duplicate implementations of prefix/suffix string comparison - functions have been unified to starts_with() and ends_with(). - - * The new PERLLIB_EXTRA makefile variable can be used to specify - additional directories Perl modules (e.g. the ones necessary to run - git-svn) are installed on the platform when building. - - * "git merge-base" learned the "--fork-point" mode, that implements - the same logic used in "git pull --rebase" to find a suitable fork - point out of the reflog entries for the remote-tracking branch the - work has been based on. "git rebase" has the same logic that can be - triggered with the "--fork-point" option. - - * A third-party "receive-pack" (the responder to "git push") can - advertise the "no-thin" capability to tell "git push" not to use - the thin-pack optimization. Our receive-pack has always been - capable of accepting and fattening a thin-pack, and will continue - not to ask "git push" to use a non-thin pack. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v1.8.5 ------------------- - -Unless otherwise noted, all the fixes since v1.8.5 in the maintenance -track are contained in this release (see the maintenance releases' notes -for details). - - * The pathspec matching code, while comparing two trees (e.g. "git - diff A B -- path1 path2") was too aggressive and failed to match - some paths when multiple pathspecs were involved. - (merge e4ddb05 as/tree-walk-fix-aggressive-short-cut later to maint). - - * "git repack --max-pack-size=8g" stopped being parsed correctly when - the command was reimplemented in C. - (merge b861e23 sb/repack-in-c later to maint). - - * An earlier update in v1.8.4.x to "git rev-list --objects" with - negative ref had a performance regression. - (merge 200abe7 jk/mark-edges-uninteresting later to maint). - - * A recent update to "git send-email" broke platforms where - /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path - (e.g. Fedora rawhide). - (merge 01645b7 rk/send-email-ssl-cert later to maint). - - * A handful of bugs around interpreting $branch@{upstream} notation - and its lookalike, when $branch part has interesting characters, - e.g. "@", and ":", have been fixed. - (merge 9892d5d jk/interpret-branch-name-fix later to maint). - - * "git clone" would fail to clone from a repository that has a ref - directly under "refs/", e.g. "refs/stash", because different - validation paths do different things on such a refname. Loosen the - client side's validation to allow such a ref. - (merge 4c22408 jk/allow-fetch-onelevel-refname later to maint). - - * "git log --left-right A...B" lost the "leftness" of commits - reachable from A when A is a tag as a side effect of a recent - bugfix. This is a regression in 1.8.4.x series. - (merge a743528 jc/revision-range-unpeel later to maint). - - * documentations to "git pull" hinted there is an "-m" option because - it incorrectly shared the documentation with "git merge". - (merge 08f19cf jc/maint-pull-docfix later to maint). - - * "git diff A B submod" and "git diff A B submod/" ought to have done - the same for a submodule "submod", but didn't. - - * "git clone $origin foo\bar\baz" on Windows failed to create the - leading directories (i.e. a moral-equivalent of "mkdir -p"). - - * "submodule.*.update=checkout", when propagated from .gitmodules to - .git/config, turned into a "submodule.*.update=none", which did not - make much sense. - (merge efa8fd7 fp/submodule-checkout-mode later to maint). - - * The implementation of 'git stash $cmd "stash@{...}"' did not quote - the stash argument properly and left it split at IFS whitespace. - (merge 2a07e43 ow/stash-with-ifs later to maint). - - * The "--[no-]informative-errors" options to "git daemon" were parsed - a bit too loosely, allowing any other string after these option - names. - (merge 82246b7 nd/daemon-informative-errors-typofix later to maint). - - * There is no reason to have a hardcoded upper limit for the number of - parents of an octopus merge, created via the graft mechanism, but - there was. - (merge e228c17 js/lift-parent-count-limit later to maint). - - * The basic test used to leave unnecessary trash directories in the - t/ directory. - (merge 738a8be jk/test-framework-updates later to maint). - - * "git merge-base --octopus" used to leave cleaning up suboptimal - result to the caller, but now it does the clean-up itself. - (merge 8f29299 bm/merge-base-octopus-dedup later to maint). - - * A "gc" process running as a different user should be able to stop a - new "gc" process from starting, but it didn't. - (merge ed7eda8 km/gc-eperm later to maint). - - * An earlier "clean-up" introduced an unnecessary memory leak. - (merge e1c1a32 jk/credential-plug-leak later to maint). - - * "git add -A" (no other arguments) in a totally empty working tree - used to emit an error. - (merge 64ed07c nd/add-empty-fix later to maint). - - * "git log --decorate" did not handle a tag pointed by another tag - nicely. - (merge 5e1361c bc/log-decoration later to maint). - - * When we figure out how many file descriptors to allocate for - keeping packfiles open, a system with non-working getrlimit() could - cause us to die(), but because we make this call only to get a - rough estimate of how many are available and we do not even attempt - to use up all available file descriptors ourselves, it is nicer to - fall back to a reasonable low value rather than dying. - (merge 491a8de jh/rlimit-nofile-fallback later to maint). - - * read_sha1_file(), that is the workhorse to read the contents given - an object name, honoured object replacements, but there was no - corresponding mechanism to sha1_object_info() that was used to - obtain the metainfo (e.g. type & size) about the object. This led - callers to weird inconsistencies. - (merge 663a856 cc/replace-object-info later to maint). - - * "git cat-file --batch=", an admittedly useless command, did not - behave very well. - (merge 6554dfa jk/cat-file-regression-fix later to maint). - - * "git rev-parse -- " did not implement the usual - disambiguation rules the commands in the "git log" family used in - the same way. - (merge 62f162f jk/rev-parse-double-dashes later to maint). - - * "git mv A B/", when B does not exist as a directory, should error - out, but it didn't. - (merge c57f628 mm/mv-file-to-no-such-dir-with-slash later to maint). - - * A workaround to an old bug in glibc prior to glibc 2.17 has been - retired; this would remove a side effect of the workaround that - corrupts system error messages in non-C locales. - - * SSL-related options were not passed correctly to underlying socket - layer in "git send-email". - (merge 5508f3e tr/send-email-ssl later to maint). - - * "git commit -v" appends the patch to the log message before - editing, and then removes the patch when the editor returned - control. However, the patch was not stripped correctly when the - first modified path was a submodule. - (merge 1a72cfd jl/commit-v-strip-marker later to maint). - - * "git fetch --depth=0" was a no-op, and was silently ignored. - Diagnose it as an error. - (merge 5594bca nd/transport-positive-depth-only later to maint). - - * Remote repository URLs expressed in scp-style host:path notation are - parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks - to connect to user's home directory on host at address ::1. - (merge a2036d7 tb/clone-ssh-with-colon-for-port later to maint). - - * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the - command line parser. - (merge 887c6c1 nd/magic-pathspec later to maint). - - * "git cat-file --batch-check=ok" did not check the existence of - the named object. - (merge 4ef8d1d sb/sha1-loose-object-info-check-existence later to maint). - - * "git am --abort" sometimes complained about not being able to write - a tree with an 0{40} object in it. - (merge 77b43ca jk/two-way-merge-corner-case-fix later to maint). - - * Two processes creating loose objects at the same time could have - failed unnecessarily when the name of their new objects started - with the same byte value, due to a race condition. - (merge b2476a6 jh/loose-object-dirs-creation-race later to maint). diff --git a/Documentation/git.txt b/Documentation/git.txt index 795015269..02bbc084b 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -43,6 +43,11 @@ unreleased) version of Git, that is available from 'master' branch of the `git.git` repository. Documentation for older releases are available here: +* link:v1.9.0/git.html[documentation for release 1.9.0] + +* release notes for + link:RelNotes/1.9.0.txt[1.9.0]. + * link:v1.8.5.5/git.html[documentation for release 1.8.5.5] * release notes for diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN index 79058e5a3..2b97352dd 100755 --- a/GIT-VERSION-GEN +++ b/GIT-VERSION-GEN @@ -1,7 +1,7 @@ #!/bin/sh GVF=GIT-VERSION-FILE -DEF_VER=v1.9.0-rc3 +DEF_VER=v1.9.0 LF=' ' diff --git a/RelNotes b/RelNotes index c300119d9..bb52cf947 120000 --- a/RelNotes +++ b/RelNotes @@ -1 +1 @@ -Documentation/RelNotes/1.9.txt \ No newline at end of file +Documentation/RelNotes/1.9.0.txt \ No newline at end of file -- cgit v1.2.1