Matthias Andree wrote: > Am 14.05.2009, 15:42 Uhr, schrieb Sverre Rabbelier <srabbelier@xxxxxxxxx>: > >> Heya, >> >> On Thu, May 14, 2009 at 15:39, Matthias Andree >> <matthias.andree@xxxxxx> wrote: >>> The bug itself (references to 'deleted' or 'replaced' tag objects remain >>> reachable rather than becoming dangling) is still there without a >>> suggestion >>> to the solution, and you're uselessly the bug. >> >> I believe Alex is saying that this is not a bug, but intended >> behavior, and Matthias is saying that we should change that behavior >> so that users are at least aware that they are creating such a >> situation, is that correct? > > I think my statements are: > > 1- git tag -d and git tag -f do not work as advertised for tag objects (as > opposed to lightweight tags); evidence in the longish mail Both of these do indeed work. In your examples 'git tag -d' worked as intended. The tag was deleted even though the object still remained in the object database. The tag subcommand does not remove objects. Objects which are not used anymore are removed by running the 'git gc' command. This happens automatically periodically. If you want to see them disappear now, run 'git gc --prune=now'. In your examples, 'git tag -f' worked as intended. The "object" referenced by the command line arguments was tagged, and the existing tag was replaced by a new tag with the same name. So when you do $ git tag -f -m 'add tag foo' foo foo the second foo is dereferenced, and it's object id is what is tagged. So it is equivalent to the following: $ git tag -f -m 'add tag foo' foo 2e326d8a210536b7cd1f2bc77e3e29d7231f9ec4 This object happens to be a tag object which points to a commit. Your graph: objects: 4481a1 (commit) <- 2e326d (tag "foo") <- 72f346 (tag "foo") is perfectly correct and valid. The middle tag object does not exist in the tag namespace though. Its name is embedded in the tag object and is necessary for validating the tag object. > 2- I presume that the bug cannot be really fixed (signed tags created by > somebody else), we then have several solutions: > 2a- warn the user and refuse > 2b- warn the user and continue nonetheless > 2c- warn the user and add options to force the user should at least be > warned that he may be doing something which doesn't work as intended, or > 2d- give the user a possibility to force git to do stupid things. There are no 'cycles', there is no inconsistency, there is no bug, except perhaps in git fast-export. -brandon -- 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