git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Feb 20, 2014, 11:06 UTC
Message-ID
<5305E1A9.1050203@alum.mit.edu>
In-Reply-To
<alpine.LSU.2.11.1402192356480.1491@nerf08.vanv.qr>
On 02/19/2014 11:58 PM, Jan Engelhardt wrote:
Show 23 quoted lines
> 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/
Previous: Jan EngelhardtNext: Jan Engelhardt
Message 4 of 6 in “release-notes could be clearer on git-fetch changes”
  1. Jan EngelhardtFeb 19, 2014
  2. Junio C HamanoFeb 19, 2014
  3. Jan EngelhardtFeb 19, 2014
  4. Michael HaggertyFeb 20, 2014
  5. Jan EngelhardtFeb 20, 2014
  6. Jan EngelhardtFeb 20, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.