Junio C Hamano wrote:
>"Stephen R. van den Berg" <srb@xxxxxxx> writes:
>> ..., it currently stores any tags
>> directly in refs/tags,...
>which is consistent with the way all the native Porcelain commands handle
>tags. There is no per-remote namespace for tags in git Porcelain.
There is in git-svn.
>For some people, the patch would be an improvement, but for some other
>people, this would be a regression.
Due to the quirks of CVS (and SVN), over time many CVS/SVN repositories
have picked up a lot of tags which either made sense at the time (but
don't anymore), or have not been wiped because of the
difficulty/impossibility to do so in the old repository.
The usual way to import from CVS is to do the import, then pick the
branches and tags you really want to keep, copy/replicate them outside
remotes and then move on in a clean fashion.
Rerunning cvsimport on a regular basis causes the import to (re)create
all the tags from CVS again; if this is done in your regular tags space,
this is a mess at best, or overwrites whatever renamed tags you
carefully created which happen to match with old CVS tagnames.
git-svn *does* use the tags namespace under remotes, so it does it the
'proper' way.
With respect to the concern that all git porcelain works without a
separate remotes/.../tags namespace, two things:
- git-svn and git-cvsimport cross the boundary to a different VCS and
therefore can/should use an extra barrier before (auto)converting to
git native tags (and branches).
- I personally would find it most natural when upon cloning a git
repository not only the branches cloned end up in a separate remotes
namespace (like they do now already), but that the tags would do the same
(e.g. in remotes/.../tags).
Even if this behaviour is not deemed "good" to be a new default, I'd
strongly suggest to at least make it optional using an appropriate flag
(and respective git-config variable to make it the local default).
--
Sincerely, srb@xxxxxxx
Stephen R. van den Berg.
"It is better for civilization to be going down the drain than
to be coming up it."
--
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
