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@xxxxxxxxxxxxxxxxxxx/ explains. > >> -----Original Message----- >> From: Bryan Turner [mailto:bturner@xxxxxxxxxxxxx]V >> Sent: 19 April 2018 23:14 >> To: Andrew Ducker >> Cc: git@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxxx> 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
