# release-notes could be clearer on git-fetch changes 6 messages from 2014-02-19 to 2014-02-20. Participants: Jan Engelhardt, Junio C Hamano, Michael Haggerty. Thread: https://gitlist.dev/t/35915 ## Jan Engelhardt, 2014-02-19 18:53 Subject: release-notes could be clearer on git-fetch changes Message-ID: URL: https://gitlist.dev/e/alpine.LSU.2.11.1402191952070.31131%40nerf08.vanv.qr ``` Greetings. The release notes for 1.9.0 read: > * The "--tags" option to "git fetch" no longer tells the command to > fetch _only_ the tags. It instead fetches tags _in addition to_ > what are fetched by the same command line without the option. I think the release notes should also say -- like it was done extensively for git add -- how to get back the old behavior (perhaps through now-different commands). thanks, Jan ``` ## Junio C Hamano, 2014-02-19 20:01 Subject: Re: release-notes could be clearer on git-fetch changes Message-ID: URL: https://gitlist.dev/e/xmqqtxbu98ie.fsf%40gitster.dls.corp.google.com In-Reply-To: ``` Jan Engelhardt writes: > The release notes for 1.9.0 read: > >> * The "--tags" option to "git fetch" no longer tells the command to >> fetch _only_ the tags. It instead fetches tags _in addition to_ >> what are fetched by the same command line without the option. > > I think the release notes should also say -- like it was done > extensively for git add -- how to get back the old > behavior (perhaps through now-different commands). Perhaps, but the release note is not a place to repeat what the documentation already teaches---it primarily is to enumerate the changed areas, to highlight the things users may want to look up in the documentation, to give them a starting point. You would do something like this, I would think: git fetch $there 'refs/tags/*:refs/tags/*' ``` ## Jan Engelhardt, 2014-02-19 22:58 Subject: Re: release-notes could be clearer on git-fetch changes Message-ID: URL: https://gitlist.dev/e/alpine.LSU.2.11.1402192356480.1491%40nerf08.vanv.qr In-Reply-To: ``` On Wednesday 2014-02-19 21:01, Junio C Hamano wrote: >Jan Engelhardt writes: >> The release notes for 1.9.0 read: >> >>> * The "--tags" option to "git fetch" no longer tells the command to >>> fetch _only_ the tags. It instead fetches tags _in addition to_ >>> what are fetched by the same command line without the option. >> >> I think the release notes should also say -- like it was done >> extensively for git add -- how to get back the old >> behavior (perhaps through now-different commands). > >Perhaps, but the release note is not a place to repeat what the >documentation already teaches---it primarily is to enumerate the >changed areas, to highlight the things users may want to look up in the >documentation, to give them a starting point. > >You would do something like this, I would think: > > git fetch $there 'refs/tags/*:refs/tags/*' Looking at it from one more angle, `git fetch r --tags` and `git push r --tags` is now no longer symmetric :( ``` ## Jan Engelhardt, 2014-02-20 09:51 Subject: Re: release-notes could be clearer on git-fetch changes Message-ID: URL: https://gitlist.dev/e/alpine.LSU.2.11.1402200821010.6991%40nerf08.vanv.qr In-Reply-To: ``` On Thursday 2014-02-20 00:40, Junio C Hamano wrote: >On Wed, Feb 19, 2014 at 2:58 PM, Jan Engelhardt wrote: > Looking at it from one more angle, `git fetch r --tags` and >`git push r --tags` is now no longer symmetric :( > > >I would have loved to hear such comments _during_ the discussion, not after >a release is made, Perhaps, though I only became aware of this change because LWN reported about git 1.9.0. ``` ## Michael Haggerty, 2014-02-20 11:06 Subject: Re: release-notes could be clearer on git-fetch changes Message-ID: <5305E1A9.1050203@alum.mit.edu> URL: https://gitlist.dev/e/5305E1A9.1050203%40alum.mit.edu In-Reply-To: ``` On 02/19/2014 11:58 PM, Jan Engelhardt wrote: > On Wednesday 2014-02-19 21:01, Junio C Hamano wrote: >> Jan Engelhardt writes: >>> The release notes for 1.9.0 read: >>> >>>> * The "--tags" option to "git fetch" no longer tells the command to >>>> fetch _only_ the tags. It instead fetches tags _in addition to_ >>>> what are fetched by the same command line without the option. >>> >>> I think the release notes should also say -- like it was done >>> extensively for git add -- how to get back the old >>> behavior (perhaps through now-different commands). >> >> Perhaps, but the release note is not a place to repeat what the >> documentation already teaches---it primarily is to enumerate the >> changed areas, to highlight the things users may want to look up in the >> documentation, to give them a starting point. >> >> You would do something like this, I would think: >> >> git fetch $there 'refs/tags/*:refs/tags/*' > > Looking at it from one more angle, `git fetch r --tags` and > `git push r --tags` is now no longer symmetric :( I'm glad you brought this up, because I didn't really think about whether "git push" would need changes parallel to those in "git fetch". I use "git push" in very conservative ways, so I don't know its ins and outs. What scenarios do you find asymmetric? Were they more symmetric before? Perhaps you don't like that when some branch is configured for pushing via remote.$remote.push, so that git push $remote would push something, then you would expect git push --tags $remote to push the same something *plus* the tags. But I'm not sure that is desirable. Pushing is a lot more traumatic than fetching, because any mistakes are obvious to all of your collaborators. So I think it is OK that the command is more reticent about pushing things that were specified implicitly. One thing I personally don't like is that git push $remote --all --tags is not allowed. I would expect it to push all branches and all tags. But at least it just emits an error rather than doing something unexpected. Michael -- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/ ``` ## Jan Engelhardt, 2014-02-20 17:54 Subject: Re: release-notes could be clearer on git-fetch changes Message-ID: URL: https://gitlist.dev/e/alpine.LSU.2.11.1402201754370.11221%40nerf08.vanv.qr In-Reply-To: ``` On Thu, 20 Feb 2014 12:06:17, Michael Haggerty wrote: >On 02/19/2014 11:58 PM, Jan Engelhardt wrote: >> >> Looking at it from one more angle, `git fetch r --tags` and >> `git push r --tags` is now no longer symmetric :( > >I'm glad you brought this up, because I didn't really think about >whether "git push" would need changes parallel to those in "git fetch". > >I use "git push" in very conservative ways, so I don't know its ins and >outs. What scenarios do you find asymmetric? Were they more symmetric >before? `git push r --tags` pushes only tags, and `git fetch r --tags` only fetched tags. Starting from 1.9.0, `git fetch r --tags`, according to the release summary, changed to "tags and other things". That's the asymmetric change I find. It is, as you say, undesirable to have `git push r --tags` push more than tags, which is why I am objecting (acknowledging it's after-the-fact) that the change to git-fetch was so-so. A new option `git fetch r --only-tags` could remedy the hard-to-remember syntax `git fetch r "refs/tags/*:refs/tags/*"`, though it would not fix the asymmetry. ```