Re: remote branches

Björn Steinbrink [off-list ref] writes:

It's ok for fetch to treat --tags like a refspec and to have it override
the defaults from the config when the user manually specifies it on the
command line. But when it is part of the default configuration it should
add to remote.<name>.fetch, not override it.

IOW with this configuration:
remote.foo.url = git://host/repo.git
remote.foo.fetch = +refs/heads/*:refs/remotes/foo/*
remote.foo.tagopt = --tags

"git fetch foo" acts like:

git fetch --tags git://host/repo.git

instead of

git fetch --tags git://host/repo.git +refs/heads/*:refs/remotes/foo/*

I would agree that the behaviour of tagopt acting exactly as if the
options were given from the command line is an ungly hack, not an intended
behaviour.  Interested in coming up with a proposed approach for a fix?

I would say --tags from the command line probably outlived its original
purpose; back when we didn't have the reliable automatic following,
sometimes people needed to say "fetch --tags" to complete the set of tags.
The description in config.txt for --tags also cites another purpose,
namely, to fetch tags otherwise totally unrelated to the branches you are
following, but in reality there is no sensible use case to require such a
feature.  Yes, you may have many unrelated lines of development with
separate set of tags on them, but then --tags to fetch _all_ tags from
all of these unrelated lines of development is a too coarse-grained tool
to be useful.

Note that "fetch --tags" without following any of the branches _is_ a
sensible setting for a rather common workflow.

For every active developer who will have his own private changes in the
repository, there would be 100 passive followers who would fetch the
branches of the project and build the bleeding edge (i.e. nightly
builders) and these two classes of people would benefit from having
"refs/heads/*:refs/remotes/origin/*" refspec.  And for each of these
people, there would be 100 people who would be interested only in tagged
releases.  They of course could download tarballs, but they can instead
say "fetch --tags", check out the latest tagged release and use it.

2011/2/14 Junio C Hamano [off-list ref]:

The description in config.txt for --tags also cites another purpose,
namely, to fetch tags otherwise totally unrelated to the branches you are
following, but in reality there is no sensible use case to require such a
feature.  Yes, you may have many unrelated lines of development with
separate set of tags on them, but then --tags to fetch _all_ tags from
all of these unrelated lines of development is a too coarse-grained tool
to be useful.

FWIW, here's my use case: I'm doing development on two separate
computers, and I'm synchronizing my work between those by fetching
from each other computer directly (not pushing through a common repo),
i.e. "git remote add other b:/home/me/foo/.git" in ~/foo/.git on
computer a and "git remote add other a:/home/me/foo/.git" on computer
b. Now I often drop partial work, rebase it etc., and make tags before
the dropping, and sometimes I want to revisit those tagged (but not
otherwise reachable) commits, and for that I want them to be available
on both computers. I too searched the config docs, tried "tagopts =
--tags" and then wondered why it wouldn't sync my branches anymore,
then moved to "fetch = +refs/tags/*:refs/tags/*".

Christian.