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@evledraar.gmail.com/
explains.

>
>> -Original Message-
>> From: Bryan Turner [mailto:btur...@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_duc...@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
>> >* branchmaster -> 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..tagOpt setting. See
>> git-config(1).
>>
>> By comparison, on your "git pull $repo $currentBranch", what you're
>> calling "$currentBranch" is actually "[...]" 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 ...
>>  * branchmaster -> FETCH_HEAD
>>aca5eb0fef5..ad484477508  master -> origin/master
>>
>> As you can see, both FETC

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:btur...@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_duc...@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
> >* branchmaster -> 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..tagOpt setting. See
> git-config(1).
>
> By comparison, on your "git pull $repo $currentBranch", what you're
> calling "$currentBranch" is actually "[...]" 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 ...
>  * branchmaster -> 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 - Standa

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
 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
>* branchmaster -> 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..tagOpt setting. See
git-config(1).

By comparison, on your "git pull $repo $currentBranch", what you're
calling "$currentBranch" is actually "[...]" 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 ...
 * branchmaster -> 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

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
   * branchmaster -> 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