docs: Clarify that tag fetch defaults did not change in v6#9
Open
AriehSchneier wants to merge 1 commit intogo-git:mainfrom
Open
docs: Clarify that tag fetch defaults did not change in v6#9AriehSchneier wants to merge 1 commit intogo-git:mainfrom
AriehSchneier wants to merge 1 commit intogo-git:mainfrom
Conversation
7612b47 to
d8152e4
Compare
Section 3 was misleading - it said tag defaults didn't change, but missed the key point: the *implementation* of TagFollowing was fixed in v6. What actually happened: - The default (TagFollowing) did not change - BUT v5 had a bug where TagFollowing fetched ALL tags (including those pointing to tree/blob objects) - v6 transport refactor (Dec 2024) fixed TagFollowing to correctly match git's behavior: only fetch tags pointing to commits being fetched - PR #1459 fixed a test that relied on the buggy behavior TagFollowing should use git's include-tag capability to fetch only annotated tags pointing to commits in the fetched history. The v5 implementation incorrectly fetched all tags. Impact: Users who relied on TagFollowing fetching all tags (bug) now need to explicitly set Tags: AllTags. Changes made: - Corrected section title to reflect the bug fix - Explained v5 had buggy TagFollowing implementation - Clarified v6 fixed it to match git CLI behavior - Updated migration guidance for users who relied on the bug - Added clear examples showing the before/after behavior Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Arieh Schneier <15041913+AriehSchneier@users.noreply.github.com>
d8152e4 to
d21188b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Section 3 of the migration guide was misleading. It stated that tag fetch defaults didn't change, but it missed the critical point: the implementation of
TagFollowingwas fixed in v6 to match git's actual behavior.What Actually Happened
The default didn't change:
FetchOptions.Tagsdefaults toTagFollowingFetchOptions.Tagsdefaults toTagFollowingBUT the implementation of
TagFollowingwas buggy in v5 and fixed in v6:v5 (buggy):
TagFollowingincorrectly fetched all tags from the remotev6 (fixed):
TagFollowingcorrectly uses git'sinclude-tagcapabilitygit fetch(without--tags)Why the test needed fixing:
TagFollowingTags: AllTagsWhat is
TagFollowing?Per git spec,
TagFollowingshould:include-tagcapability to fetch tags during fetchAllTags)This matches
git fetchbehavior without--tagsor--no-tags.Migration Impact
If you relied on
TagFollowingfetching all tags (the v5 bug):You now need to explicitly set
Tags: git.AllTagsIf you only need tags pointing to fetched commits (correct behavior):
No change needed - v6 now works correctly
Changes Made
TagFollowingimplementation fixed to match git behavior"References
88f21adb(v6 transport refactor that fixed TagFollowing)