threads / discuss / 35915
Subject: release-notes could be clearer on git-fetch changes
Jan EngelhardtGreetings.
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 HamanoRe: release-notes could be clearer on git-fetch changes
Jan Engelhardt <jengelh@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/*'
Jan EngelhardtRe: release-notes could be clearer on git-fetch changes
On Wednesday 2014-02-19 21:01, Junio C Hamano wrote:
>Jan Engelhardt <jengelh@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 :(
Michael HaggertyRe: 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 <jengelh@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 mhagger@alum.mit.edu http://softwareswirl.blogspot.com/
Jan EngelhardtRe: 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.
Jan EngelhardtRe: 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 <jengelh@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.