Re: Potential bug in git client

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]