release-notes could be clearer on git-fetch changes

release-notes could be clearer on git-fetch changes

[Jan Engelhardt]

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

Re: release-notes could be clearer on git-fetch changes

[Junio C Hamano]

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/*'

Re: release-notes could be clearer on git-fetch changes

[Jan Engelhardt]

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 :(

Re: release-notes could be clearer on git-fetch changes

[Jan Engelhardt]

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.

Re: release-notes could be clearer on git-fetch changes

[Michael Haggerty]

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/

Re: release-notes could be clearer on git-fetch changes

[Jan Engelhardt]

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.