pagure

#4718 Fix the view_commit endpoint when the identifier provided is a git tag
Merged by pingou. Opened by pingou.
view_commit_tags  into  master

Download 4718.patch
no initial comment

I miss some tests that can actually check that the content wé are rendering is from the tag and is not present on {master,default} branches. Could we put the tag on a different object than ref/head and check content?
Edited by jlanda

we have the commit already, why redirect? Rendering directly the tag on the same execution will be faster that redirecting to self and could allow use to render the tag label somewhere on the same time (after redirect we don't know that the user used a tagname as argument)

At first I thought about doing as you say but then I figured that it was kinda wrong since the hash provided is not a commit, so rather than showing as a commit something that isn't one, I figured it would be more semantically correct to redirect the users to the proper page.

The tag is on the first commit in the repo, which contains two commits. So at the time the tag is rendered, it's no longer HEAD.
Does that make sense?

9 new commits added

  • Fix the view_commit endpoint when the identifier provided is a git tag
  • Only consider the most recently active branches for new PR
  • Rework the UI for the file history page
  • Add unit-tests for the view file's history feature
  • Add a link to the file's history in the file's blame page
  • Add a link to the file's history in the file's view page
  • Add a new endpoint and page to see a file's history
  • Add a method to run git log using the system's git
  • Enable running a command in a specific folder and return the output

9 new commits added

  • Fix the view_commit endpoint when the identifier provided is a git tag
  • Only consider the most recently active branches for new PR
  • Rework the UI for the file history page
  • Add unit-tests for the view file's history feature
  • Add a link to the file's history in the file's blame page
  • Add a link to the file's history in the file's view page
  • Add a new endpoint and page to see a file's history
  • Add a method to run git log using the system's git
  • Enable running a command in a specific folder and return the output

At first I thought about doing as you say but then I figured that it was kinda wrong since the hash provided is not a commit, so rather than showing as a commit something that isn't one, I figured it would be more semantically correct to redirect the users to the proper page.

I did not realized that. I like the reasoning

The tag is on the first commit in the repo, which contains two commits. So at the time the tag is rendered, it's no longer HEAD.
Does that make sense?

:thumbsup:

:thumbsup:

rebased onto d05f1d05ac7601d35705737cc4e858295b390f1a

rebased onto b88d6605e28836844f73f18655ba681c3bbe8604

Pull-Request has been merged by pingou
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.