git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Potential bug in git client

From
WPWojciech Przybył <przybylwojciech@gmail.com>
Date
Jun 17, 2014, 09:38 UTC
Message-ID
<CAKY5LXzGo5CTTnVL86GduO-bXaqNPuBSj=K3jUu4Kz=g6HHFYw@mail.gmail.com>
In-Reply-To
<53A0079B.1030602@alum.mit.edu>

Hi Thanks, it's exactly what I was after.

BTW Just looking at ubuntu packages (I was using 12.04LTS) and it looks like in a recent LTS release (14.04LTS) they still have git version 1.9.1, and only on utopic ubuntu (the newest one) git is 2.0.0. Anyway, it's probably good time to upgrade.

Many thanks for your reply.

Cheers Wojciech

On 17 June 2014 10:17, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 84 quoted lines
> On 06/11/2014 12:21 PM, Wojciech Przybył wrote:
>> When I was tagging, I think I might have discovered a git client bug.
>> [...]
>> HOW TO REPRODUCE:
>> - Clone a repo into 2 separate directories. Presume there is a tag
>> "v0.1" already in there and it is set on say 10 commits ago.
>>
>> - In first directory change the tag to a different place and push it
>> to the server:
>> git tag -d v0.1
>> git tag v0.1
>> git push --tags origin master
>>
>> - In second directory try to update the tag...
>> git pull --all --tags
>> git fetch -all --tags
>> THIS DOES NOT WORK, tag is still at old place, but it says "Already up-to-date".
>>
>> - I noticed when I use:
>> git fetch --tags
>> it works fine and updates the position of the tag, or if I remove tag
>> from local git manually (rm .git/refs/tags/v0.1) and update again.
>>
>> Is it a bug or I am doing something wrong? I use git version 1.7.9.5.
>
> Tag fetching changed quite a bit in v1.9.0.  Here is a similar test
> using Git 2.0.0:
>
> $ git init main
> Initialized empty Git repository in /home/mhagger/tmp/tagexp/main/.git/
> $ cd main
> $ git commit --allow-empty -m Initial
> [master (root-commit) fdcd35b] Initial
> $ git tag t
> $ git commit --allow-empty -m Second
> [master 88f7d4a] Second
> $ cd ..
> $ git clone main clone1
> Cloning into 'clone1'...
> done.
> $ git clone main clone2
> Cloning into 'clone2'...
> done.
> $ cd clone1
> $ git tag -d t
> Deleted tag 't' (was fdcd35b)
> $ git tag t
> $ git push --tags origin master
> To /home/mhagger/tmp/tagexp/main
>  ! [rejected]        t -> t (already exists)
> error: failed to push some refs to '/home/mhagger/tmp/tagexp/main'
> hint: Updates were rejected because the tag already exists in the remote.
>
> So, it is impossible to overwrite tags on the server by pushing with the
> --tags option.  But we can use a force push:
>
> $ git push origin +refs/tags/t
> Total 0 (delta 0), reused 0 (delta 0)
> To /home/mhagger/tmp/tagexp/main
>  + fdcd35b...88f7d4a t -> t (forced update)
> $ cd ../clone2
> $ git pull --all --tags
> Fetching origin
> From /home/mhagger/tmp/tagexp/main
>  - [tag update]      t          -> t
> Already up-to-date.
>
> So, the tag is now updated but with a visible display of what happened.
>  Similarly with fetch:
>
> $ git update-ref refs/tags/t HEAD^
> $ git fetch --all --tags
> Fetching origin
> From /home/mhagger/tmp/tagexp/main
>  - [tag update]      t          -> t
>
> Is this closer to the behavior that you want?
>
> Michael
>
> --
> Michael Haggerty
> mhagger@alum.mit.edu
>
Previous: Michael Haggerty
Message 5 of 5 in “Potential bug in git client”
  1. Wojciech PrzybyłJun 11, 2014
  2. Stefan BellerJun 11, 2014
  3. Wojciech PrzybyłJun 11, 2014
  4. Michael HaggertyJun 17, 2014
  5. Wojciech PrzybyłJun 17, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.