On 11-02-01 10:35 AM, Nguyen Thai Ngoc Duy wrote:
On Tue, Feb 1, 2011 at 10:07 PM, Marc Branchaud<marcnarc@xxxxxxxxxxx> wrote:
Config branch.*.globalTags (perhaps takes a pattern?) may be defined
to create refs/tags/* in addition to refs/remote-tags/<remote>/* when
fetching tags.
I may be getting into the weeds prematurely here, but why put the config item
under branch.* ? Or did you mean remote.*.globalTags? Personally, I don't
see a need for this. I'd rather have the rev-parse machinery search in
remote tag namespaces if it can't find anything local.
Ahh.. yeah it's remote.*.globalTags. I don't know, some people might
find current behavior useful. So instead of dropping it entirely, I'd
limit it to certain remotes.
IMHO, it's best not to assume what people might want. Better to wait
for someone to ask for something specific.
[ ...snip... ]
When tags are put in remote namespace (wherever it actually is),
git-tag must learn -r like git-branch. I think option name change for
-a is too late though. When "git-ng" rewrite project comes (that is
after libgit2 replaces git core), we may have everything consistent
again.
I think we could start by making "git tag -A" a synonym for "git tag -a"
with a verbose warning when "-a" is used that it'll soon gain a
different meaning.
Also, during the transition "git tag -a" without any other options could
(without the big warning) list all local and remote tags (like "git
branch -a") and if someone wanted to make an annotated tag of the
current tip they could do "git tag -A" or "git tag -a HEAD".
M.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html