Bug Report - Pull remote branch does not retrieve new tags

Bug Report - Pull remote branch does not retrieve new tags

[Andrew Ducker]

What happens:
When I create a new tag on the remote (changing nothing else)
"git pull origin master" produces the following:
  From git.internal.company.com:team/testrepo
   * branch            master     -> FETCH_HEAD
  Already up-to-date.

If I instead do a "git pull" I get:
  From git.internal.company.com:team/testrepo
   * [new tag]         Testing11  -> Testing11
  Already up-to-date.

What I think should happen:
The "git pull origin master" should retrieve the tag.

This is with 2.16.2.windows.1, but also occurred on my previously installed version (2.12.2.windows.2)

My understanding is that "git pull" and "git pull $repo $currentbranch" should function identically.

Is this a bug, or am I misunderstanding the manual page?

Thanks,

Andy
Confidentiality - This email is confidential.
Not meant for you? - If you don't think this email is meant for you, please let us know. Do not copy or forward the information it contains, and delete this email from your system.
Views expressed - Any personal views or opinions expressed in this email are the sender's, and do not necessarily reflect the views of Standard Life Aberdeen group.
Monitoring - We filter and monitor emails to protect our systems and to keep them running smoothly.
Emailing us - Email isn't a secure form of communication. If you want to send us confidential information please send it by post. However, if you do communicate with us by email on any subject, you are giving us permission to email you back.
Phoning us - Calls may be monitored and/or recorded to protect both you and us and help with our training. Call charges will vary.
Standard Life Aberdeen group - Standard Life Aberdeen group comprises Standard Life Aberdeen plc and its subsidiaries. For more information on Standard Life Aberdeen group visit our website http://www.standardlifeaberdeen.com/.
Standard Life Aberdeen plc (SC286832), Standard Life Assurance Limited (SC286833) and Standard Life Employee Services Limited (SC271355) are all registered in Scotland at Standard Life House, 30 Lothian Road, Edinburgh EH1 2DH. Standard Life Assurance Limited is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.
For more information on Standard Life Assurance limited visit our website http://www.standardlife.co.uk

Re: Bug Report - Pull remote branch does not retrieve new tags

[Bryan Turner]

Andrew,

On Thu, Apr 19, 2018 at 6:55 AM, Andrew Ducker
<andrew_ducker@standardlife.com> wrote:
>
> What happens:
> When I create a new tag on the remote (changing nothing else)
> "git pull origin master" produces the following:
>   From git.internal.company.com:team/testrepo
>    * branch            master     -> FETCH_HEAD
>   Already up-to-date.
>
> If I instead do a "git pull" I get:
>   From git.internal.company.com:team/testrepo
>    * [new tag]         Testing11  -> Testing11
>   Already up-to-date.
>
> What I think should happen:
> The "git pull origin master" should retrieve the tag.
>
> This is with 2.16.2.windows.1, but also occurred on my previously installed version (2.12.2.windows.2)
>
> My understanding is that "git pull" and "git pull $repo $currentbranch" should function identically.
>
> Is this a bug, or am I misunderstanding the manual page?

Looks like a misunderstanding, to me. Perhaps I can help clarify.

"git pull" without arguments fetches from the "origin" repository
using the configured "fetch" refspecs, which typically looks something
like "fetch = +refs/heads/*:refs/remotes/origin/*". It _doesn't_
actually fetch all tags, but any tag referencing any object/commit
included in the branches is brought along for the ride. This is
documented on "git pull":

--no-tags

    By default, tags that point at objects that are downloaded from
the remote repository are fetched and stored locally. This option
disables this automatic tag following. The default behavior for a
remote may be specified with the remote.<name>.tagOpt setting. See
git-config(1).

By comparison, on your "git pull $repo $currentBranch", what you're
calling "$currentBranch" is actually "[<refspec>...]" from the
documentation. In other words, by passing "master", you've told "git
pull" to fetch _nothing but "master"_, ignoring the configured
refspec(s). Additionally, since you haven't told "git pull" where to
_put_ "master" once it's fetched, it writes it to "FETCH_HEAD". If you
have a tracking branch setup, "git pull origin master" will also
update the tracking branch. For example, the same command for me
produces:

$ git pull origin master
From ...
 * branch                    master     -> FETCH_HEAD
   aca5eb0fef5..ad484477508  master     -> origin/master

As you can see, both FETCH_HEAD and origin/master were updated, since
my local "master" tracks "origin"'s "master":

[branch "master"]
        remote = origin
        merge = refs/heads/master

Hope this helps!
Bryan

RE: Bug Report - Pull remote branch does not retrieve new tags

[Andrew Ducker]

Thanks Bryan, that does clear it up a bit.

The reason that this came up is that Visual Studio Code has switched from "git pull" to "git pull remote branch" when the "sync" button is clicked, and this has meant that tags are no longer being fetched.

What _does_ seem to work is adding "--tags" on the end of the git pull.  But this isn't actually in the documentation[1], and I'm a bit nervous that this is mid-deprecation.

Is "--tags" going away shortly?  Or are they ok to depend on this?

The bug is at https://github.com/Microsoft/vscode/issues/48211 if anyone wants to chime in with advice over there :-)

Thanks,

Andy

> -----Original Message-----
> From: Bryan Turner [mailto:bturner@atlassian.com]
> Sent: 19 April 2018 23:14
> To: Andrew Ducker
> Cc: git@vger.kernel.org
> Subject: Re: Bug Report - Pull remote branch does not retrieve new tags
>
> Andrew,
>
> On Thu, Apr 19, 2018 at 6:55 AM, Andrew Ducker
> <andrew_ducker@standardlife.com> wrote:
> >
> > What happens:
> > When I create a new tag on the remote (changing nothing else)
> > "git pull origin master" produces the following:
> >   From git.internal.company.com:team/testrepo
> >    * branch            master     -> FETCH_HEAD
> >   Already up-to-date.
> >
> > If I instead do a "git pull" I get:
> >   From git.internal.company.com:team/testrepo
> >    * [new tag]         Testing11  -> Testing11
> >   Already up-to-date.
> >
> > What I think should happen:
> > The "git pull origin master" should retrieve the tag.
> >
> > This is with 2.16.2.windows.1, but also occurred on my previously installed
> version (2.12.2.windows.2)
> >
> > My understanding is that "git pull" and "git pull $repo $currentbranch"
> should function identically.
> >
> > Is this a bug, or am I misunderstanding the manual page?
>
> Looks like a misunderstanding, to me. Perhaps I can help clarify.
>
> "git pull" without arguments fetches from the "origin" repository
> using the configured "fetch" refspecs, which typically looks something
> like "fetch = +refs/heads/*:refs/remotes/origin/*". It _doesn't_
> actually fetch all tags, but any tag referencing any object/commit
> included in the branches is brought along for the ride. This is
> documented on "git pull":
>
> --no-tags
>
>     By default, tags that point at objects that are downloaded from
> the remote repository are fetched and stored locally. This option
> disables this automatic tag following. The default behavior for a
> remote may be specified with the remote.<name>.tagOpt setting. See
> git-config(1).
>
> By comparison, on your "git pull $repo $currentBranch", what you're
> calling "$currentBranch" is actually "[<refspec>...]" from the
> documentation. In other words, by passing "master", you've told "git
> pull" to fetch _nothing but "master"_, ignoring the configured
> refspec(s). Additionally, since you haven't told "git pull" where to
> _put_ "master" once it's fetched, it writes it to "FETCH_HEAD". If you
> have a tracking branch setup, "git pull origin master" will also
> update the tracking branch. For example, the same command for me
> produces:
>
> $ git pull origin master
> From ...
>  * branch                    master     -> FETCH_HEAD
>    aca5eb0fef5..ad484477508  master     -> origin/master
>
> As you can see, both FETCH_HEAD and origin/master were updated, since
> my local "master" tracks "origin"'s "master":
>
> [branch "master"]
>         remote = origin
>         merge = refs/heads/master
>
> Hope this helps!
> Bryan
Confidentiality - This email is confidential.
Not meant for you? - If you don't think this email is meant for you, please let us know. Do not copy or forward the information it contains, and delete this email from your system.
Views expressed - Any personal views or opinions expressed in this email are the sender's, and do not necessarily reflect the views of Standard Life Aberdeen group.
Monitoring - We filter and monitor emails to protect our systems and to keep them running smoothly.
Emailing us - Email isn't a secure form of communication. If you want to send us confidential information please send it by post. However, if you do communicate with us by email on any subject, you are giving us permission to email you back.
Phoning us - Calls may be monitored and/or recorded to protect both you and us and help with our training. Call charges will vary.
Standard Life Aberdeen group - Standard Life Aberdeen group comprises Standard Life Aberdeen plc and its subsidiaries. For more information on Standard Life Aberdeen group visit our website http://www.standardlifeaberdeen.com/.
Standard Life Aberdeen plc (SC286832), Standard Life Assurance Limited (SC286833) and Standard Life Employee Services Limited (SC271355) are all registered in Scotland at Standard Life House, 30 Lothian Road, Edinburgh EH1 2DH. Standard Life Assurance Limited is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.
For more information on Standard Life Assurance limited visit our website http://www.standardlife.co.uk

Re: Bug Report - Pull remote branch does not retrieve new tags

[Ævar Arnfjörð Bjarmason]

On Fri, Apr 20 2018, Andrew Ducker wrote:

> Thanks Bryan, that does clear it up a bit.
>
> The reason that this came up is that Visual Studio Code has switched from "git pull" to "git pull remote branch" when the "sync" button is clicked, and this has meant that tags are no longer being fetched.
>
> What _does_ seem to work is adding "--tags" on the end of the git pull.  But this isn't actually in the documentation[1], and I'm a bit nervous that this is mid-deprecation.
>
> Is "--tags" going away shortly?  Or are they ok to depend on this?
>
> The bug is at https://github.com/Microsoft/vscode/issues/48211 if anyone wants to chime in with advice over there :-)

It's in the documentation, it's just in the git-fetch documentation, and
the git-pull docs say:

    More precisely, git pull runs git fetch with the given parameters

So --tags is not going away, however using --tags is likely not the
right thing either, because it'll also get tags that don't point to any
of the refs being tracked as the docs explain, which isn't what was
happening with "git pull".

As to what VS /should/ be doing, I have no idea because I don't know why
they switched away from "git pull" to "git pull remote branch" in the
first place. Maybe they'd like to clone with --single-branch?

Unfortunately there's no way to replicate that on an existing repo
without re-cloning, as my
https://public-inbox.org/git/874lkuvtve.fsf@evledraar.gmail.com/
explains.

>
>> -----Original Message-----
>> From: Bryan Turner [mailto:bturner@atlassian.com]V
>> Sent: 19 April 2018 23:14
>> To: Andrew Ducker
>> Cc: git@vger.kernel.org
>> Subject: Re: Bug Report - Pull remote branch does not retrieve new tags
>>
>> Andrew,
>>
>> On Thu, Apr 19, 2018 at 6:55 AM, Andrew Ducker
>> <andrew_ducker@standardlife.com> wrote:
>> >
>> > What happens:
>> > When I create a new tag on the remote (changing nothing else)
>> > "git pull origin master" produces the following:
>> >   From git.internal.company.com:team/testrepo
>> >    * branch            master     -> FETCH_HEAD
>> >   Already up-to-date.
>> >
>> > If I instead do a "git pull" I get:
>> >   From git.internal.company.com:team/testrepo
>> >    * [new tag]         Testing11  -> Testing11
>> >   Already up-to-date.
>> >
>> > What I think should happen:
>> > The "git pull origin master" should retrieve the tag.
>> >
>> > This is with 2.16.2.windows.1, but also occurred on my previously installed
>> version (2.12.2.windows.2)
>> >
>> > My understanding is that "git pull" and "git pull $repo $currentbranch"
>> should function identically.
>> >
>> > Is this a bug, or am I misunderstanding the manual page?
>>
>> Looks like a misunderstanding, to me. Perhaps I can help clarify.
>>
>> "git pull" without arguments fetches from the "origin" repository
>> using the configured "fetch" refspecs, which typically looks something
>> like "fetch = +refs/heads/*:refs/remotes/origin/*". It _doesn't_
>> actually fetch all tags, but any tag referencing any object/commit
>> included in the branches is brought along for the ride. This is
>> documented on "git pull":
>>
>> --no-tags
>>
>>     By default, tags that point at objects that are downloaded from
>> the remote repository are fetched and stored locally. This option
>> disables this automatic tag following. The default behavior for a
>> remote may be specified with the remote.<name>.tagOpt setting. See
>> git-config(1).
>>
>> By comparison, on your "git pull $repo $currentBranch", what you're
>> calling "$currentBranch" is actually "[<refspec>...]" from the
>> documentation. In other words, by passing "master", you've told "git
>> pull" to fetch _nothing but "master"_, ignoring the configured
>> refspec(s). Additionally, since you haven't told "git pull" where to
>> _put_ "master" once it's fetched, it writes it to "FETCH_HEAD". If you
>> have a tracking branch setup, "git pull origin master" will also
>> update the tracking branch. For example, the same command for me
>> produces:
>>
>> $ git pull origin master
>> From ...
>>  * branch                    master     -> FETCH_HEAD
>>    aca5eb0fef5..ad484477508  master     -> origin/master
>>
>> As you can see, both FETCH_HEAD and origin/master were updated, since
>> my local "master" tracks "origin"'s "master":
>>
>> [branch "master"]
>>         remote = origin
>>         merge = refs/heads/master
>>
>> Hope this helps!
>> Bryan
> Confidentiality - This email is confidential.
> Not meant for you? - If you don't think this email is meant for you, please let us know. Do not copy or forward the information it contains, and delete this email from your system.
> Views expressed - Any personal views or opinions expressed in this email are the sender's, and do not necessarily reflect the views of Standard Life Aberdeen group.
> Monitoring - We filter and monitor emails to protect our systems and to keep them running smoothly.
> Emailing us - Email isn't a secure form of communication. If you want to send us confidential information please send it by post. However, if you do communicate with us by email on any subject, you are giving us permission to email you back.
> Phoning us - Calls may be monitored and/or recorded to protect both you and us and help with our training. Call charges will vary.
> Standard Life Aberdeen group - Standard Life Aberdeen group comprises Standard Life Aberdeen plc and its subsidiaries. For more information on Standard Life Aberdeen group visit our website http://www.standardlifeaberdeen.com/.
> Standard Life Aberdeen plc (SC286832), Standard Life Assurance Limited (SC286833) and Standard Life Employee Services Limited (SC271355) are all registered in Scotland at Standard Life House, 30 Lothian Road, Edinburgh EH1 2DH. Standard Life Assurance Limited is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.
> For more information on Standard Life Assurance limited visit our website http://www.standardlife.co.uk