Re: release-notes could be clearer on git-fetch changes
On Thursday 2014-02-20 00:40, Junio C Hamano wrote: On Wed, Feb 19, 2014 at 2:58 PM, Jan Engelhardt jeng...@inai.de 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: release-notes could be clearer on git-fetch changes
On 02/19/2014 11:58 PM, Jan Engelhardt wrote: On Wednesday 2014-02-19 21:01, Junio C Hamano wrote: Jan Engelhardt jeng...@inai.de 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 mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: release-notes could be clearer on git-fetch changes
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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
release-notes could be clearer on git-fetch changes
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: release-notes could be clearer on git-fetch changes
Jan Engelhardt jeng...@inai.de 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/*' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
