List for cgit developers and users
 help / color / mirror / Atom feed
From: wub at partyvan.eu (Juuso Lapinlampi)
Subject: Snapshot URLs can conflict with two similar but unique tags
Date: Mon, 23 May 2016 04:57:33 +0000	[thread overview]
Message-ID: <20160523045733.GA2784@partyvan.eu> (raw)

Steps to reproduce bug:

  Create a repository with two tags, one prefixed with "v"-character and
  one without. These tags should reference two unique SHA-1 objects.

  For the sake of argument and following along, I will use an existing
  repository as a following example to reproduce the issue.

    $ git clone https://git.pantsu.cat/pantsu/pomf/
    Cloning into 'pomf'...
    Checking connectivity... done.
    $ cd pomf/
    $ git tag | grep "1.0.0$"
    1.0.0
    v1.0.0
    $ git log --oneline --decorate -n 1 1.0.0
    7f9d1cb (tag: 1.0.0) Add package.json and Gruntfile.js
    $ git log --oneline --decorate -n 1 v1.0.0
    687b1be (tag: v1.0.0) Merge branch 'nuck-dev'

  Setup cgit with this repository.

  Configure `snapshots` option in `cgitrc` for at least one file
  supported snapshot format (e.g. `.tar`, `.zip`) to enable snapshots.

    # Allow download of tar.gz, tar.bz2 and zip-files
    snapshots=tar.gz tar.xz zip

  Open a browser and go to `$schema://$cgit_uri/$repository/` (example:
  [1]). Look for a snapshot URL on the index page or in tag detail page at
  /$repository/tag/?h=$tag.

Expected behavior:

  (git.pantsu.cat is used as an example.)

  In somewhat simplified version, the HTML index document may be
  expected to look like:

    Tag     Download
    [...]
    v1.0.0  pomf-v1.0.0.zip pomf-v1.0.0.tar.gz pomf-v1.0.0.tar.xz
    [...]
    1.0.0   pomf-1.0.0.zip  pomf-1.0.0.tar.gz  pomf-1.0.0.tar.xz 

  In somewhat simplified version, the HTML tag detail document may be
  expected to look like the following example for tag v1.0.0:

    download  pomf-v1.0.0.zip
              pomf-v1.0.0.tar.gz
              pomf-v1.0.0.tar.xz

  In example, the download URL for 1.0.0 .zip snapshot is expected to be
  found at one or more of the following unique locations (adapt for
  other file extensions):

    https://git.pantsu.cat/pantsu/pomf/snapshot/1.0.0/pomf-1.0.0.zip
    https://git.pantsu.cat/pantsu/pomf/snapshot/pomf-1.0.0.zip

  In example, the download URL for v1.0.0 .zip snapshot is expected to
  be found at one or more of the following unique locations (adapt for
  other file extensions):

    https://git.pantsu.cat/pantsu/pomf/snapshot/v1.0.0/pomf-1.0.0.zip
    https://git.pantsu.cat/pantsu/pomf/snapshot/pomf-v1.0.0.zip

  The contents of both snapshots when extracted are expected to match
  those of v1.0.0 and 1.0.0 tags, respectively.

  The /$repository/snapshot/$tag/$project-$version.$ext syntax is a
  suggested enhancement to resolve the issue while keeping traditional
  file names without the "v"-prefix, if such functionality is desired.

Actual behavior:

  (git.pantsu.cat is used as an example.)

  In somewhat simplified version, the HTML document actually looks like:

    Tag     Download
    [...]
    v1.0.0  pomf-1.0.0.zip  pomf-1.0.0.tar.gz  pomf-1.0.0.tar.xz
    [...]
    1.0.0   pomf-1.0.0.zip  pomf-1.0.0.tar.gz  pomf-1.0.0.tar.xz 

  In somewhat simplified version, the HTML tag detail document for tag
  v1.0.0 actually looks like:

    download  pomf-1.0.0.zip
              pomf-1.0.0.tar.gz
              pomf-1.0.0.tar.xz

  In example, the .zip snapshot for tag 1.0.0 is hyperlinked to the
  following URL (adapt for other file extensions):

    https://git.pantsu.cat/pantsu/pomf/snapshot/pomf-1.0.0.zip

  In example, the .zip snapshot for tag v1.0.0 is hyperlinked to the
  same URL as 1.0.0 (adapt for other file extensions):

    https://git.pantsu.cat/pantsu/pomf/snapshot/pomf-1.0.0.zip

  The contents of snapshot downloaded from v1.0.0 tag hyperlink when
  extracted match that of 1.0.0 tag.

  In other words, cgit knows of snapshot named pomf-v1.0.0.zip (or
  alternative configured snapshot extension) and will happily serve it
  correctly when requested, but never links to it.

Version number:

  cgit v0.12

Operating system:

  CentOS 7

Notes:

  The "Pro Git" book by Scott Chacon and Ben Straub suggests prefixing
  tags with "v".[2] git.git follows this convention.[3]

[1]: https://git.pantsu.cat/pantsu/pomf/
[2]: https://git-scm.com/book/en/v2/Git-Basics-Tagging
[3]: https://git.kernel.org/cgit/git/git.git/refs/tags


             reply	other threads:[~2016-05-23  4:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-23  4:57 wub [this message]
2016-05-23  5:11 ` wub
2016-05-24 16:15 ` [PATCH] Avoid ambiguities when prettifying snapshot names lfleischer
2016-07-02 13:30   ` lfleischer
2016-07-02 20:04   ` Jason
2016-07-05 14:13   ` Jason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160523045733.GA2784@partyvan.eu \
    --to=cgit@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).