Skip to content

docs: Clarify that tag fetch defaults did not change in v6#9

Open
AriehSchneier wants to merge 1 commit intogo-git:mainfrom
AriehSchneier:fix-tags-default-section
Open

docs: Clarify that tag fetch defaults did not change in v6#9
AriehSchneier wants to merge 1 commit intogo-git:mainfrom
AriehSchneier:fix-tags-default-section

Conversation

@AriehSchneier
Copy link
Copy Markdown
Contributor

@AriehSchneier AriehSchneier commented Apr 6, 2026

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 TagFollowing was fixed in v6 to match git's actual behavior.

What Actually Happened

The default didn't change:

  • v5: FetchOptions.Tags defaults to TagFollowing
  • v6: FetchOptions.Tags defaults to TagFollowing

BUT the implementation of TagFollowing was buggy in v5 and fixed in v6:

v5 (buggy):

  • TagFollowing incorrectly fetched all tags from the remote
  • This included tags pointing to tree objects, blob objects, everything
  • This was NOT matching git CLI behavior

v6 (fixed):

  • TagFollowing correctly uses git's include-tag capability
  • Only fetches annotated tags that point to commits in the fetched history
  • Now matches git CLI behavior: git fetch (without --tags)

Why the test needed fixing:

  • PR #1459 fixed a test that relied on the buggy v5 behavior
  • The test expected tags pointing to tree/blob objects to be fetched with TagFollowing
  • After the v6 transport refactor (Dec 2024) fixed the implementation, the test needed to explicitly set Tags: AllTags

What is TagFollowing?

Per git spec, TagFollowing should:

  • Use the include-tag capability to fetch tags during fetch
  • Only fetch tags that point to commits being fetched
  • NOT fetch tags pointing to trees, blobs, or unreachable commits
  • NOT fetch all tags (that's AllTags)

This matches git fetch behavior without --tags or --no-tags.

Migration Impact

If you relied on TagFollowing fetching all tags (the v5 bug):
You now need to explicitly set Tags: git.AllTags

If you only need tags pointing to fetched commits (correct behavior):
No change needed - v6 now works correctly

Changes Made

  1. Corrected section 3 title: "TagFollowing implementation fixed to match git behavior"
  2. Explained the v5 bug: TagFollowing was fetching all tags (incorrect)
  3. Explained the v6 fix: Now correctly uses include-tag capability
  4. Updated impact statement: Users relying on the bug need to use AllTags
  5. Added clear migration examples: Shows before/after with explanations
  6. Referenced the transport refactor: Dec 2024 fix in v6

References

@AriehSchneier AriehSchneier requested a review from pjbgf April 6, 2026 11:22
@AriehSchneier AriehSchneier force-pushed the fix-tags-default-section branch from 7612b47 to d8152e4 Compare April 6, 2026 12:01
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>
@AriehSchneier AriehSchneier force-pushed the fix-tags-default-section branch from d8152e4 to d21188b Compare April 6, 2026 12:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant