[ANNOUNCE] git-filter-repo v2.27.0 (Was: Re: [ANNOUNCE] Git v2.27.0)
Hi, On Mon, Jun 1, 2020 at 9:37 AM Junio C Hamano wrote: > > The latest feature release Git v2.27.0 is now available at the > usual places. It is comprised of 537 non-merge commits since > v2.26.0, contributed by 71 people, 19 of which are new faces. The latest release of git-filter-repo, v2.27.0, is also now available. It is comprised of 26 non-merge commits since v2.26.0, including two changes from new contributors. If you have been holding off on trying filter-repo because you didn't want to figure out how to convert your filter-branch or BFG commands, there are now cheat sheets for converting any example from the manual of either of those tools into equivalent filter-repo commands; see the last two links here: https://github.com/newren/git-filter-repo#how-do-i-use-it The public repo of filter-repo is at https://github.com/newren/git-filter-repo The tarballs can be found at: https://github.com/newren/git-filter-repo/releases git-filter-repo can also be installed via a variety of package managers across Windows, Mac OS, or Linux (and maybe others)[1]. New contributors whose contributions weren't in v2.26.0 are as follows. Welcome to the git-filter-repo development community! * Kate F * Marius Renner [1] https://github.com/newren/git-filter-repo/blob/master/INSTALL.md git-filter-repo 2.27 Release Notes == (Note: Additional information is available for many release notes at https://github.com/newren/git-filter-repo/issues/) * Fixes: * fix ugly bug with mixing path filtering and renaming (#96) * suggest --no-local when cloning local repos (discourage use of --force) * fix possible deadlock in sanity_check_args (#86) * fix --prune-degenerate=never with path filtering (#92) * throw an error if user specifies any path starting with a slash (#73) * ensure we write final newline after final progress update (#84) * repack with --source or --target (#66) * make --version more robust against modified shebangs * make git version requirement error message more direct (#94) * allow removing .git directories from history * Documentation: * fix typo in example (#69) * add more detailed explanation of safety checks and --force * add guides & cheat sheets for people converting from filter-branch or BFG * add examples for --subdirectory-filter and --to-subdirectory-filter * add missing documentation for --no-ff option (#92) * add more --paths-from-file examples with large filtering lists * clarify usage of --use-base-name * streamline install instructions a bit * and various other miscellaneous improvements and fixes * contrib scripts: * fix special character handling in filter-lamely (#71) * Miscellaneous: * add sanity checks around release script Changes since v2.26.0 are as follows: Elijah Newren (24): Makefile: a few sanity checks for releasing filter-repo: fix bitrotted documentation links filter-repo: suggest --no-local when cloning local repos filter-repo: ensure we write final newline after final progress update filter-repo: make --version more robust against modified shebangs filter-repo: clarify usage of --use-base-name git-filter-repo.txt: add examples for --[to-]subdirectory-filter filter-repo: throw an error if user specifies any path starting with a slash git-filter-repo.txt: add documentation of --no-ff option filter-repo: allow removing .git directories from history Documentation: add guides for people converting from filter-branch or BFG git-filter-repo.txt: add more --paths-from-file examples with large filtering lists INSTALL: streamline a bit and guide folks to package managers filter-repo: fix --no-local error when there is no remote Documentation: add more detailed explanation of safety checks and --force filter-repo: make git version requirement error message more direct filter-repo: fix possible deadlock in sanity_check_args filter-repo: fix ugly bug with mixing path filtering and renaming filter-repo: fix --prune-degenerate=never with path filtering git-filter-repo.txt: fix extraneous space filter-repo: repack with --source or --target filter-repo (README): link cheat sheets from usage section too filter-repo (README): separate sections for different tools git-filter-repo.txt: connect --no-local and fresh clones more thoroughly Kate F (1): git-filter-repo.txt: Fix typo for example Marius Renner (1): contrib: fix special character handling in filter-lamely
[ANNOUNCE] Git v2.27.0
The latest feature release Git v2.27.0 is now available at the usual places. It is comprised of 537 non-merge commits since v2.26.0, contributed by 71 people, 19 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.27.0' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.26.0 are as follows. Welcome to the Git development community! Andras Kucsma, Ansgar Röber, Ash Holland, Christopher Warrington, Emma Brooks, Jan Engelhardt, Jessica Clarke, Jorge Lopez Silva, Julien Moutinho, Li Xuejiang, luciano.ro...@booking.com, Matthias Aßhauer, Michael F. Schönitzer, Nathan Sanders, Son Luong Ngoc, Terry Moschou, Toon Claes, Vasil Dimov, and Yang Zhao. Returning contributors who helped this release are as follows. Thanks for your continued support. 마누엘, Abhishek Kumar, Alban Gruin, Alessandro Menti, Alexander Shopov, Alexandr Miloslavskiy, Alex Henrie, Andrei Rybak, Andrew Oakley, Ben Keene, brian m. carlson, Carlo Marcelo Arenas Belón, Christian Couder, Christopher Diaz Riveros, Damien Robert, Denton Liu, Derrick Stolee, Đoàn Trần Công Danh, Elijah Newren, Emily Shaffer, Emir Sarı, Eric Sunshine, Garima Singh, Greg Price, Hans Jerry Illikainen, Heba Waly, Ismael Luceno, Jean-Noël Avila, Jeff King, Jiang Xin, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Jordi Mas, Josh Steadmon, Junio C Hamano, Martin Ågren, Matheus Tavares, Matthias Rüster, Patrick Steinhardt, Peter Krefting, Philippe Blain, Phillip Wood, Pratyush Yadav, René Scharfe, Shourya Shukla, SZEDER Gábor, Taylor Blau, Thomas Gummerer, Todd Zullinger, Trần Ngọc Quân, and Yi-Jyun Pan. Git 2.27 Release Notes == Updates since v2.26 --- Backward compatibility notes * When "git describe C" finds that commit C is pointed by a signed or annotated tag, which records T as its tagname in the object, the command gives T as its answer. Even if the user renames or moves such a tag from its natural location in the "refs/tags/" hierarchy, "git describe C" would still give T as the answer, but in such a case "git show T^0" would no longer work as expected. There may be nothing at "refs/tags/T" or even worse there may be a different tag instead. Starting from this version, "git describe" will always use the "long" version, as if the "--long" option were given, when giving its output based on such a misplaced tag to work around the problem. * "git pull" issues a warning message until the pull.rebase configuration variable is explicitly given, which some existing users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning. * The transport protocol version 2, which was promoted to the default in Git 2.26 release, turned out to have some remaining rough edges, so it has been demoted from the default. UI, Workflows & Features * A handful of options to configure SSL when talking to proxies have been added. * Smudge/clean conversion filters are now given more information (e.g. the object of the tree-ish in which the blob being converted appears, in addition to its path, which has already been given). * When "git describe C" finds an annotated tag with tagname A to be the best name to explain commit C, and the tag is stored in a "wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the command gave a warning message but used A (not B) to describe C. If C is exactly at the tag, the describe output would be "A", but "git rev-parse A^0" would not be equal as "git rev-parse C^0". The behavior of the command has been changed to use the "long" form i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse. * "git pull" learned to warn when no pull.rebase configuration exists, and neither --[no-]rebase nor --ff-only is given (which would result a merge). * "git p4" learned four new hooks and also "--no-verify" option to bypass them (and the existing "p4-pre-submit" hook). * "git pull" shares many options with underlying "git fetch", but some of them were not documented and some of those that would make sense to pass down were not passed down. * "git rebase" learned the "--no-gpg-sign" option to countermand commit.gpgSign the user may have. * The output from "git format-patch" uses RFC 2047 encoding for non-ASCII letters on From: and Subject: headers, so that it can directly be fed to e-mail programs. A new option has been added to produce these headers in raw. * "git log" learned "--show-pulls" that helps pathspec limited history views; a merge
Re: [ANNOUNCE] Git v2.27.0-rc2
On 27 May 2020 22:17:01 GMT+05:30, Junio C Hamano wrote: >Kaartic Sivaraam writes: > >> Hi Junio, >> >> On 27-05-2020 00:17, Junio C Hamano wrote: >>> Shourya Shukla (4): >>>submodule--helper.c: Rename 'cb_foreach' to 'foreach_cb' >>>gitfaq: files in .gitignore are tracked >>>gitfaq: fetching and pulling a repository >>>submodule: port subcommand 'set-url' from shell to C >> >> This is the only place where the `set-url` conversion from Shell to C >> is mentioned. I wonder if it's enough or if it needs a little bit >more >> attention may be in the "Performance, Internal Implementation, >> Development Support etc." as it is a conversion of a submodule >> sub-command? > >I'm not sure if it is worth the bits. It may matter _only_ if/when >new implementaiton of set-url hurts the end-users by being buggy ;-) OK. That makes sense. The converted version has gone through reviews and presumably it does pass our CI test cases. I think I was just trying to overcautious to ensure we're not bitten by a worst case scenario wherein a bug slipped through the reviews and the tests. I believe it's pretty unlikely, though :-) -- Sivaraam Sent from my Android device with K-9 Mail. Please excuse my brevity and possible "typso".
Re: [ANNOUNCE] Git v2.27.0-rc2
Pratyush Yadav writes: > On 26/05/20 11:47AM, Junio C Hamano wrote: >> A release candidate Git v2.27.0-rc2 is now available for testing >> at the usual places. It is comprised of 509 non-merge commits >> since v2.26.0, contributed by 59 people, 17 of which are new faces. >> >> Changes since v2.26.0 are as follows: >> >> Ansgar Röber (1): >> Subject: git-gui: fix syntax error because of missing semicolon > > Looks like I messed up somewhere and left the "Subject: " in there. Its > too late to do anything about it now I guess... Yup, indeed you did ;-) But we all make mistakes and learn from the ones we or others make, so...
Re: [ANNOUNCE] Git v2.27.0-rc2
Kaartic Sivaraam writes: > Hi Junio, > > On 27-05-2020 00:17, Junio C Hamano wrote: >> Shourya Shukla (4): >>submodule--helper.c: Rename 'cb_foreach' to 'foreach_cb' >>gitfaq: files in .gitignore are tracked >>gitfaq: fetching and pulling a repository >>submodule: port subcommand 'set-url' from shell to C > > This is the only place where the `set-url` conversion from Shell to C > is mentioned. I wonder if it's enough or if it needs a little bit more > attention may be in the "Performance, Internal Implementation, > Development Support etc." as it is a conversion of a submodule > sub-command? I'm not sure if it is worth the bits. It may matter _only_ if/when new implementaiton of set-url hurts the end-users by being buggy ;-)
Re: [ANNOUNCE] Git v2.27.0-rc2
On 26/05/20 11:47AM, Junio C Hamano wrote: > A release candidate Git v2.27.0-rc2 is now available for testing > at the usual places. It is comprised of 509 non-merge commits > since v2.26.0, contributed by 59 people, 17 of which are new faces. > > Changes since v2.26.0 are as follows: > > Ansgar Röber (1): > Subject: git-gui: fix syntax error because of missing semicolon Looks like I messed up somewhere and left the "Subject: " in there. Its too late to do anything about it now I guess... -- Regards, Pratyush Yadav
Re: [ANNOUNCE] Git v2.27.0-rc2
Hi Junio, On 27-05-2020 00:17, Junio C Hamano wrote: Shourya Shukla (4): submodule--helper.c: Rename 'cb_foreach' to 'foreach_cb' gitfaq: files in .gitignore are tracked gitfaq: fetching and pulling a repository submodule: port subcommand 'set-url' from shell to C This is the only place where the `set-url` conversion from Shell to C is mentioned. I wonder if it's enough or if it needs a little bit more attention may be in the "Performance, Internal Implementation, Development Support etc." as it is a conversion of a submodule sub-command? I'm not sure about the importance that these kinds of conversion require, thus the question :) -- Sivaraam
[ANNOUNCE] Git v2.27.0-rc2
A release candidate Git v2.27.0-rc2 is now available for testing at the usual places. It is comprised of 509 non-merge commits since v2.26.0, contributed by 59 people, 17 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.27.0-rc2' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.26.0 are as follows. Welcome to the Git development community! Andras Kucsma, Ansgar Röber, Ash Holland, Christopher Warrington, Emma Brooks, Jessica Clarke, Jorge Lopez Silva, Julien Moutinho, Li Xuejiang, luciano.ro...@booking.com, Matthias Aßhauer, Michael F. Schönitzer, Nathan Sanders, Son Luong Ngoc, Terry Moschou, Vasil Dimov, and Yang Zhao. Returning contributors who helped this release are as follows. Thanks for your continued support. 마누엘, Abhishek Kumar, Alban Gruin, Alexandr Miloslavskiy, Alex Henrie, Andrei Rybak, Andrew Oakley, Ben Keene, brian m. carlson, Carlo Marcelo Arenas Belón, Christian Couder, Damien Robert, Denton Liu, Derrick Stolee, Đoàn Trần Công Danh, Elijah Newren, Emily Shaffer, Eric Sunshine, Garima Singh, Greg Price, Hans Jerry Illikainen, Heba Waly, Ismael Luceno, Jeff King, Jiang Xin, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C Hamano, Martin Ågren, Matheus Tavares, Patrick Steinhardt, Philippe Blain, Phillip Wood, Pratyush Yadav, René Scharfe, Shourya Shukla, SZEDER Gábor, Taylor Blau, Thomas Gummerer, and Todd Zullinger. Git 2.27 Release Notes (draft) == Updates since v2.26 --- Backward compatibility notes * When "git describe C" finds that commit C is pointed by a signed or annotated tag, which records T as its tagname in the object, the command gives T as its answer. Even if the user renames or moves such a tag from its natural location in the "refs/tags/" hierarchy, "git describe C" would still give T as the answer, but in such a case "git show T^0" would no longer work as expected. There may be nothing at "refs/tags/T" or even worse there may be a different tag instead. Starting from this version, "git describe" will always use the "long" version, as if the "--long" option were given, when giving its output based on such a misplaced tag to work around the problem. * "git pull" issues a warning message until the pull.rebase configuration variable is explicitly given, which some existing users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning. * The transport protocol version 2, which was promoted to the default in Git 2.26 release, turned out to have some remaining rough edges, so it has been demoted from the default. UI, Workflows & Features * A handful of options to configure SSL when talking to proxies have been added. * Smudge/clean conversion filters are now given more information (e.g. the object of the tree-ish in which the blob being converted appears, in addition to its path, which has already been given). * When "git describe C" finds an annotated tag with tagname A to be the best name to explain commit C, and the tag is stored in a "wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the command gave a warning message but used A (not B) to describe C. If C is exactly at the tag, the describe output would be "A", but "git rev-parse A^0" would not be equal as "git rev-parse C^0". The behavior of the command has been changed to use the "long" form i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse. * "git pull" learned to warn when no pull.rebase configuration exists, and neither --[no-]rebase nor --ff-only is given (which would result a merge). * "git p4" learned four new hooks and also "--no-verify" option to bypass them (and the existing "p4-pre-submit" hook). * "git pull" shares many options with underlying "git fetch", but some of them were not documented and some of those that would make sense to pass down were not passed down. * "git rebase" learned the "--no-gpg-sign" option to countermand commit.gpgSign the user may have. * The output from "git format-patch" uses RFC 2047 encoding for non-ASCII letters on From: and Subject: headers, so that it can directly be fed to e-mail programs. A new option has been added to produce these headers in raw. * "git log" learned "--show-pulls" that helps pathspec limited history views; a merge commit that takes the whole change from a side branch, which is normally omitted from the output, is shown in addition to the commits that introduce real
Protocol v2 in v2.27 (Re: Re* [ANNOUNCE] Git v2.27.0-rc1)
(other lists -> bcc)
Junio C Hamano wrote:
> Jeff King writes:
>> Is it worth mentioning here the reversion of v2 as the default protocol?
>>
>> It does end up (along with the actual code fix) in the "fixes from
>> v2.26" section:
>>
>>> * Those fetching over protocol v2 from linux-next and other kernel
>>>repositories are reporting that v2 often fetches way too much than
>>>needed.
>>>(merge 11c7f2a30b jn/demote-proto2-from-default later to maint).
>>>
>>> * The upload-pack protocol v2 gave up too early before finding a
>>>common ancestor, resulting in a wasteful fetch from a fork of a
>>>project. This has been corrected to match the behaviour of v0
>>>protocol.
>>>(merge 2f0a093dd6 jt/v2-fetch-nego-fix later to maint).
>>
>> but that's somewhat buried. I dunno. It is not likely to introduce _new_
>> compatibility issues, but perhaps folks looking into compatibility stuff
>> may want to know about the revert.
>
> The promotion in Git 2.26 was buried in the "performance &
> implementation details" section and not in the backward
> compatibility section, so it feels a bit funny to highlight the
> reversion. In any case, here is what I prepared (but not committed
> yet)
Speaking of which, should we enable protocol v2 by default for people
with feature.experimental enabled, like this?
(This isn't part of the rest of the feature.experimental handling
because those are tied to a repository object, whereas this code path
is used for operations like "git ls-remote" that do not require a
repository.)
Signed-off-by: Jonathan Nieder
diff --git c/Documentation/config/protocol.txt
i/Documentation/config/protocol.txt
index 0b40141613e..c46e9b3d00a 100644
--- c/Documentation/config/protocol.txt
+++ i/Documentation/config/protocol.txt
@@ -48,7 +48,8 @@ protocol.version::
If set, clients will attempt to communicate with a server
using the specified protocol version. If the server does
not support it, communication falls back to version 0.
- If unset, the default is `0`.
+ If unset, the default is `0`, unless `feature.experimental`
+ is enabled, in which case the default is `2`.
Supported versions:
+
--
diff --git c/protocol.c i/protocol.c
index d390391ebac..d1dd3424bba 100644
--- c/protocol.c
+++ i/protocol.c
@@ -17,6 +17,7 @@ static enum protocol_version parse_protocol_version(const
char *value)
enum protocol_version get_protocol_version_config(void)
{
const char *value;
+ int val;
const char *git_test_k = "GIT_TEST_PROTOCOL_VERSION";
const char *git_test_v;
@@ -30,6 +31,9 @@ enum protocol_version get_protocol_version_config(void)
return version;
}
+ if (!git_config_get_bool("feature.experimental", ) && val)
+ return protocol_v2;
+
git_test_v = getenv(git_test_k);
if (git_test_v && *git_test_v) {
enum protocol_version env = parse_protocol_version(git_test_v);
Re: Re* [ANNOUNCE] Git v2.27.0-rc1
On Wed, May 20, 2020 at 01:31:30PM -0700, Junio C Hamano wrote: > The promotion in Git 2.26 was buried in the "performance & > implementation details" section and not in the backward > compatibility section, so it feels a bit funny to highlight the > reversion. In any case, here is what I prepared (but not committed > yet) Hmm, yeah, that does make it feel funny. I'd argue that it probably would have been worth promoting a bit more in v2.26, but it is obviously too late now. > -- >8 -- > Subject: [PATCH] RelNotes: advertise the demotion of protocol v2 What you have here looks fine, but I'd be OK if we just left it as-is, too, given the v2.26 mention. -Peff
Re: [ANNOUNCE] Git v2.27.0-rc1
Hi folks, > Shourya Shukla (4): > submodule--helper.c: Rename 'cb_foreach' to 'foreach_cb' > gitfaq: files in .gitignore are tracked > gitfaq: fetching and pulling a repository > submodule: port subcommand 'set-url' from shell to C Could you please review the minor fix in https://public-inbox.org/git/20200519045301.gy24...@pobox.com/ It helps the backward compatibility for packaging on CentOS6. Thanks, Son Luong.
Re* [ANNOUNCE] Git v2.27.0-rc1
Jeff King writes: > On Wed, May 20, 2020 at 12:17:11PM -0700, Junio C Hamano wrote: > >> Git 2.27 Release Notes (draft) >> == >> >> Updates since v2.26 >> --- >> >> Backward compatibility notes > > Is it worth mentioning here the reversion of v2 as the default protocol? > > It does end up (along with the actual code fix) in the "fixes from > v2.26" section: > >> * Those fetching over protocol v2 from linux-next and other kernel >>repositories are reporting that v2 often fetches way too much than >>needed. >>(merge 11c7f2a30b jn/demote-proto2-from-default later to maint). >> >> * The upload-pack protocol v2 gave up too early before finding a >>common ancestor, resulting in a wasteful fetch from a fork of a >>project. This has been corrected to match the behaviour of v0 >>protocol. >>(merge 2f0a093dd6 jt/v2-fetch-nego-fix later to maint). > > but that's somewhat buried. I dunno. It is not likely to introduce _new_ > compatibility issues, but perhaps folks looking into compatibility stuff > may want to know about the revert. The promotion in Git 2.26 was buried in the "performance & implementation details" section and not in the backward compatibility section, so it feels a bit funny to highlight the reversion. In any case, here is what I prepared (but not committed yet) -- >8 -- Subject: [PATCH] RelNotes: advertise the demotion of protocol v2 In the upcoming release, the transport protocol v2 is no longer the default; note it in the backward compatibility section. Suggested-by: Jeff King Signed-off-by: Junio C Hamano --- Documentation/RelNotes/2.27.0.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/RelNotes/2.27.0.txt b/Documentation/RelNotes/2.27.0.txt index 5fb8c0cf67..95a8d338ad 100644 --- a/Documentation/RelNotes/2.27.0.txt +++ b/Documentation/RelNotes/2.27.0.txt @@ -24,6 +24,10 @@ Backward compatibility notes users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning. + * The transport protocol version 2, which was promoted to the default + in Git 2.26 release, turned out to have some remaining rough edges, + so it has been demoted from the default. + UI, Workflows & Features
Re: [ANNOUNCE] Git v2.27.0-rc1
Jeff King writes: > On Wed, May 20, 2020 at 12:17:11PM -0700, Junio C Hamano wrote: > >> Git 2.27 Release Notes (draft) >> == >> >> Updates since v2.26 >> --- >> >> Backward compatibility notes > > Is it worth mentioning here the reversion of v2 as the default protocol? Yeah, that is a good suggestion. The fix inside v2 is not worth reporting, but the change of the default is noteworthy enough to be at the top.
Re: [ANNOUNCE] Git v2.27.0-rc1
On Wed, May 20, 2020 at 12:17:11PM -0700, Junio C Hamano wrote: > Git 2.27 Release Notes (draft) > == > > Updates since v2.26 > --- > > Backward compatibility notes Is it worth mentioning here the reversion of v2 as the default protocol? It does end up (along with the actual code fix) in the "fixes from v2.26" section: > * Those fetching over protocol v2 from linux-next and other kernel >repositories are reporting that v2 often fetches way too much than >needed. >(merge 11c7f2a30b jn/demote-proto2-from-default later to maint). > > * The upload-pack protocol v2 gave up too early before finding a >common ancestor, resulting in a wasteful fetch from a fork of a >project. This has been corrected to match the behaviour of v0 >protocol. >(merge 2f0a093dd6 jt/v2-fetch-nego-fix later to maint). but that's somewhat buried. I dunno. It is not likely to introduce _new_ compatibility issues, but perhaps folks looking into compatibility stuff may want to know about the revert. -Peff
[ANNOUNCE] Git v2.27.0-rc1
A release candidate Git v2.27.0-rc1 is now available for testing at the usual places. It is comprised of 491 non-merge commits since v2.26.0, contributed by 55 people, 16 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.27.0-rc1' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.26.0 are as follows. Welcome to the Git development community! Andras Kucsma, Ash Holland, Christopher Warrington, Emma Brooks, Jessica Clarke, Jorge Lopez Silva, Julien Moutinho, Li Xuejiang, luciano.ro...@booking.com, Matthias Aßhauer, Michael F. Schönitzer, Nathan Sanders, Son Luong Ngoc, Terry Moschou, Vasil Dimov, and Yang Zhao. Returning contributors who helped this release are as follows. Thanks for your continued support. 마누엘, Abhishek Kumar, Alban Gruin, Alexandr Miloslavskiy, Alex Henrie, Andrei Rybak, Andrew Oakley, Ben Keene, brian m. carlson, Carlo Marcelo Arenas Belón, Christian Couder, Damien Robert, Denton Liu, Derrick Stolee, Đoàn Trần Công Danh, Elijah Newren, Emily Shaffer, Eric Sunshine, Garima Singh, Hans Jerry Illikainen, Heba Waly, Jeff King, Jiang Xin, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C Hamano, Martin Ågren, Matheus Tavares, Patrick Steinhardt, Philippe Blain, Phillip Wood, René Scharfe, Shourya Shukla, SZEDER Gábor, Taylor Blau, Thomas Gummerer, and Todd Zullinger. Git 2.27 Release Notes (draft) == Updates since v2.26 --- Backward compatibility notes * When "git describe C" finds that commit C is pointed by a signed or annotated tag, which records T as its tagname in the object, the command gives T as its answer. Even if the user renames or moves such a tag from its natural location in the "refs/tags/" hierarchy, "git describe C" would still give T as the answer, but in such a case "git show T^0" would no longer work as expected. There may be nothing at "refs/tags/T" or even worse there may be a different tag instead. Starting from this version, "git describe" will always use the "long" version, as if the "--long" option were given, when giving its output based on such a misplaced tag to work around the problem. * "git pull" issues a warning message until the pull.rebase configuration variable is explicitly given, which some existing users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning. UI, Workflows & Features * A handful of options to configure SSL when talking to proxies have been added. * Smudge/clean conversion filters are now given more information (e.g. the object of the tree-ish in which the blob being converted appears, in addition to its path, which has already been given). * When "git describe C" finds an annotated tag with tagname A to be the best name to explain commit C, and the tag is stored in a "wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the command gave a warning message but used A (not B) to describe C. If C is exactly at the tag, the describe output would be "A", but "git rev-parse A^0" would not be equal as "git rev-parse C^0". The behavior of the command has been changed to use the "long" form i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse. * "git pull" learned to warn when no pull.rebase configuration exists, and neither --[no-]rebase nor --ff-only is given (which would result a merge). * "git p4" learned four new hooks and also "--no-verify" option to bypass them (and the existing "p4-pre-submit" hook). * "git pull" shares many options with underlying "git fetch", but some of them were not documented and some of those that would make sense to pass down were not passed down. * "git rebase" learned the "--no-gpg-sign" option to countermand commit.gpgSign the user may have. * The output from "git format-patch" uses RFC 2047 encoding for non-ASCII letters on From: and Subject: headers, so that it can directly be fed to e-mail programs. A new option has been added to produce these headers in raw. * "git log" learned "--show-pulls" that helps pathspec limited history views; a merge commit that takes the whole change from a side branch, which is normally omitted from the output, is shown in addition to the commits that introduce real changes. * The interactive input from various codepaths are consolidated and any prompt possibly issued earlier are fflush()ed before we read. * Allow "git rebase" to reapply all local commits, even if the may be already in the upstream,
[ANNOUNCE] Git v2.27.0-rc0
An early preview release Git v2.27.0-rc0 is now available for testing at the usual places. It is comprised of 479 non-merge commits since v2.26.0, contributed by 53 people, 16 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.27.0-rc0' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.26.0 are as follows. Welcome to the Git development community! Andras Kucsma, Ash Holland, Christopher Warrington, Emma Brooks, Jessica Clarke, Jorge Lopez Silva, Julien Moutinho, Li Xuejiang, luciano.ro...@booking.com, Matthias Aßhauer, Michael F. Schönitzer, Nathan Sanders, Son Luong Ngoc, Terry Moschou, Vasil Dimov, and Yang Zhao. Returning contributors who helped this release are as follows. Thanks for your continued support. 마누엘, Alban Gruin, Alexandr Miloslavskiy, Alex Henrie, Andrei Rybak, Andrew Oakley, Ben Keene, brian m. carlson, Carlo Marcelo Arenas Belón, Christian Couder, Damien Robert, Denton Liu, Derrick Stolee, Đoàn Trần Công Danh, Elijah Newren, Emily Shaffer, Eric Sunshine, Garima Singh, Hans Jerry Illikainen, Heba Waly, Jeff King, Jiang Xin, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C Hamano, Martin Ågren, Matheus Tavares, Patrick Steinhardt, Philippe Blain, Phillip Wood, René Scharfe, Shourya Shukla, SZEDER Gábor, Taylor Blau, and Thomas Gummerer. Git 2.27 Release Notes (draft) == Updates since v2.26 --- Backward compatibility notes * When "git describe C" finds that commit C is pointed by a signed or annotated tag, which records T as its tagname in the object, the command gives T as its answer. Even if the user renames or moves such a tag from its natural location in the "refs/tags/" hierarchy, "git describe C" would still give T as the answer, but in such a case "git show T^0" would no longer work as expected. There may be nothing at "refs/tags/T" or even worse there may be a different tag instead. Starting from this version, "git describe" will always use the "long" version, as if the "--long" option were given, when giving its output based on such a misplaced tag to work around the problem. * "git pull" issues a warning message until the pull.rebase configuration variable is explicitly given, which some existing users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning. UI, Workflows & Features * A handful of options to configure SSL when talking to proxies have been added. * Smudge/clean conversion filters are now given more information (e.g. the object of the tree-ish in which the blob being converted appears, in addition to its path, which has already been given). * When "git describe C" finds an annotated tag with tagname A to be the best name to explain commit C, and the tag is stored in a "wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the command gave a warning message but used A (not B) to describe C. If C is exactly at the tag, the describe output would be "A", but "git rev-parse A^0" would not be equal as "git rev-parse C^0". The behavior of the command has been changed to use the "long" form i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse. * "git pull" learned to warn when no pull.rebase configuration exists, and neither --[no-]rebase nor --ff-only is given (which would result a merge). * "git p4" learned four new hooks and also "--no-verify" option to bypass them (and the existing "p4-pre-submit" hook). * "git pull" shares many options with underlying "git fetch", but some of them were not documented and some of those that would make sense to pass down were not passed down. * "git rebase" learned the "--no-gpg-sign" option to countermand commit.gpgSign the user may have. * The output from "git format-patch" uses RFC 2047 encoding for non-ASCII letters on From: and Subject: headers, so that it can directly be fed to e-mail programs. A new option has been added to produce these headers in raw. * "git log" learned "--show-pulls" that helps pathspec limited history views; a merge commit that takes the whole change from a side branch, which is normally omitted from the output, is shown in addition to the commits that introduce real changes. * The interactive input from various codepaths are consolidated and any prompt possibly issued earlier are fflush()ed before we read. * Allow "git rebase" to reapply all local commits, even if the may be already in the upstream, without checking first.
[ANNOUNCE] Git v2.27.0-rc0
An early preview release Git v2.27.0-rc0 is now available for testing at the usual places. It is comprised of 479 non-merge commits since v2.26.0, contributed by 53 people, 16 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.27.0-rc0' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.26.0 are as follows. Welcome to the Git development community! Andras Kucsma, Ash Holland, Christopher Warrington, Emma Brooks, Jessica Clarke, Jorge Lopez Silva, Julien Moutinho, Li Xuejiang, luciano.ro...@booking.com, Matthias Aßhauer, Michael F. Schönitzer, Nathan Sanders, Son Luong Ngoc, Terry Moschou, Vasil Dimov, and Yang Zhao. Returning contributors who helped this release are as follows. Thanks for your continued support. 마누엘, Alban Gruin, Alexandr Miloslavskiy, Alex Henrie, Andrei Rybak, Andrew Oakley, Ben Keene, brian m. carlson, Carlo Marcelo Arenas Belón, Christian Couder, Damien Robert, Denton Liu, Derrick Stolee, Đoàn Trần Công Danh, Elijah Newren, Emily Shaffer, Eric Sunshine, Garima Singh, Hans Jerry Illikainen, Heba Waly, Jeff King, Jiang Xin, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C Hamano, Martin Ågren, Matheus Tavares, Patrick Steinhardt, Philippe Blain, Phillip Wood, René Scharfe, Shourya Shukla, SZEDER Gábor, Taylor Blau, and Thomas Gummerer. Git 2.27 Release Notes (draft) == Updates since v2.26 --- Backward compatibility notes * When "git describe C" finds that commit C is pointed by a signed or annotated tag, which records T as its tagname in the object, the command gives T as its answer. Even if the user renames or moves such a tag from its natural location in the "refs/tags/" hierarchy, "git describe C" would still give T as the answer, but in such a case "git show T^0" would no longer work as expected. There may be nothing at "refs/tags/T" or even worse there may be a different tag instead. Starting from this version, "git describe" will always use the "long" version, as if the "--long" option were given, when giving its output based on such a misplaced tag to work around the problem. * "git pull" issues a warning message until the pull.rebase configuration variable is explicitly given, which some existing users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning. UI, Workflows & Features * A handful of options to configure SSL when talking to proxies have been added. * Smudge/clean conversion filters are now given more information (e.g. the object of the tree-ish in which the blob being converted appears, in addition to its path, which has already been given). * When "git describe C" finds an annotated tag with tagname A to be the best name to explain commit C, and the tag is stored in a "wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the command gave a warning message but used A (not B) to describe C. If C is exactly at the tag, the describe output would be "A", but "git rev-parse A^0" would not be equal as "git rev-parse C^0". The behavior of the command has been changed to use the "long" form i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse. * "git pull" learned to warn when no pull.rebase configuration exists, and neither --[no-]rebase nor --ff-only is given (which would result a merge). * "git p4" learned four new hooks and also "--no-verify" option to bypass them (and the existing "p4-pre-submit" hook). * "git pull" shares many options with underlying "git fetch", but some of them were not documented and some of those that would make sense to pass down were not passed down. * "git rebase" learned the "--no-gpg-sign" option to countermand commit.gpgSign the user may have. * The output from "git format-patch" uses RFC 2047 encoding for non-ASCII letters on From: and Subject: headers, so that it can directly be fed to e-mail programs. A new option has been added to produce these headers in raw. * "git log" learned "--show-pulls" that helps pathspec limited history views; a merge commit that takes the whole change from a side branch, which is normally omitted from the output, is shown in addition to the commits that introduce real changes. * The interactive input from various codepaths are consolidated and any prompt possibly issued earlier are fflush()ed before we read. * Allow "git rebase" to reapply all local commits, even if the may be already in the upstream, without checking first.
