Potential bug in git client

Potential bug in git client

[Wojciech Przybył]

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

Re: Potential bug in git client

[Stefan Beller]

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

Re: Potential bug in git client

[Wojciech Przybył]

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:
> 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

Re: Potential bug in git client

[Michael Haggerty]

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

Re: Potential bug in git client

[Wojciech Przybył]

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:
> 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
>