threads / bug / 36890

Potential bug in git client

Subject: Potential bug in git client

## tl;dr

5 messages between Jun 11, 2014 and Jun 17, 2014.

replies: 4people: 3as markdown or json

Wojciech Przybył· Jun 11, 2014, 10:21 UTC · lore
Hi All
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.

Cheers Wojciech

Stefan Beller· Jun 11, 2014, 10:55 UTC · re: Wojciech Przybył · lore

Re: Potential bug in git client

On 11.06.2014 12:21, Wojciech Przybył wrote:
Show 28 quoted lines
> Hi All
> 
> 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.
> 
> Cheers
> Wojciech

Tags are intended to not change without the user knowing. To gain more understanding on that, maybe read the man page of git tag (see the discussion on retagging) https://github.com/gitster/git/blob/master/Documentation/git-tag.txt#L166

Wojciech Przybył· Jun 11, 2014, 11:09 UTC · re: Stefan Beller · lore

Re: Potential bug in git client

Hi

Thanks for your quick reply. Just read the link and I agree it is not the right thing to do, especially when someone else has already picked up the tag. In such case, I fully agree, the developer should say "I messed up, sorry".

Simultaneously, once such situation occurs, I think git should not claim all is up to date. It should not be the case on how tags are updated, that is work with "git fetch --tags", but not work with "git fetch --all --tags". I think by this developer's example, git should do the same: "I messed up, sorry, it's not actually up to date".

Cheers Wojciech

On 11 June 2014 11:55, Stefan Beller <stefanbeller@gmail.com> wrote:
Show 34 quoted lines
> On 11.06.2014 12:21, Wojciech Przybył wrote:
>> Hi All
>>
>> 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.
>>
>> Cheers
>> Wojciech
>
> Tags are intended to not change without the user knowing.
> To gain more understanding on that, maybe read the man page of
> git tag (see the discussion on retagging)
> https://github.com/gitster/git/blob/master/Documentation/git-tag.txt#L166
Michael Haggerty· Jun 17, 2014, 09:17 UTC · re: Wojciech Przybył · lore

Re: Potential bug in git client

On 06/11/2014 12:21 PM, Wojciech Przybył wrote:
Show 23 quoted lines
> 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
Wojciech Przybył· Jun 17, 2014, 09:38 UTC · re: Michael Haggerty · lore

Re: Potential bug in git client

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
>

← back to recent threads