Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • hgitaly hgitaly
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 41
    • Issues 41
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 2
    • Merge requests 2
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • heptapod
  • hgitalyhgitaly
  • Issues
  • #36

Closed
Open
Created Dec 21, 2020 by Georges Racinet@gracinet🦑Owner

Revision resolution: precedence rules

In many places, the Gitaly clients refer to commits by "revision", i.e., tag, GitLab branch or hexadecimal id. In some cases, a message called commit_id can actually be any revision.

Our resolver function, gitlab_revision_changeset, performs its lookups in the order that was convenient for implementation, but it may get precedence rules wrong. This is related to its ability to switch to the unfiltered repository automatically, which is done at the end, hence giving commit ids the lowest precedence.

The new Gitaly comparison tests should allow us to settle this down efficiently.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking