From: Michael Haggerty <mhagger@alum.mit.edu>
To: "Wojciech Przybył" <przybylwojciech@gmail.com>, git@vger.kernel.org
Subject: Re: Potential bug in git client
Date: Tue, 17 Jun 2014 11:17:15 +0200 [thread overview]
Message-ID: <53A0079B.1030602@alum.mit.edu> (raw)
In-Reply-To: <CAKY5LXywixV3dWcCcVPTvyFrScJjLd8eoVs=RA1VRcrzUgtThQ@mail.gmail.com>
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
next prev parent reply other threads:[~2014-06-17 9:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 10:21 Potential bug in git client Wojciech Przybył
2014-06-11 10:55 ` Stefan Beller
2014-06-11 11:09 ` Wojciech Przybył
2014-06-17 9:17 ` Michael Haggerty [this message]
2014-06-17 9:38 ` Wojciech Przybył
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=53A0079B.1030602@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=przybylwojciech@gmail.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).