git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen R. van den Berg" <srb@cuci.nl>
To: git@vger.kernel.org
Subject: Re: [updated PATCH] Protect current tags, import tags into remote tree
Date: Mon, 28 Apr 2008 20:48:59 +0200	[thread overview]
Message-ID: <20080428184859.GA21950@cuci.nl> (raw)
In-Reply-To: <7vmynec60v.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:
>"Stephen R. van den Berg" <srb@cuci.nl> 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@cuci.nl
           Stephen R. van den Berg.
"It is better for civilization to be going down the drain than
 to be coming up it."

  reply	other threads:[~2008-04-28 18:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-27 17:32 [updated PATCH] Protect current tags, import tags into remote tree Stephen R. van den Berg
2008-04-28 16:12 ` Junio C Hamano
2008-04-28 18:48   ` Stephen R. van den Berg [this message]
2008-04-29  6:18     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080428184859.GA21950@cuci.nl \
    --to=srb@cuci.nl \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).