Hi, On Wed, 29 Nov 2006, Jim Meyering wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > I also think that git-fetch silently updating tags is wrong. Rather, it > > should warn that the tags are different. But I've been wrong before. > > AFAIK, no one wants git-fetch to update tags _silently_. I expected it > give a diagnostic and fail by default -- and it already does that. Umm. I just tested it, and it said "updating tag" without failing. > Pushing moved tags is serious business. I was hoping to be able to use > --force to override that fail-safe. Hmmm. Probably Junio's patch is correct after all, since tags are special creatures: you do not expect them to change, but if, they can change arbitrarily (as opposed to branches, which should evolve linearly). > My goal is to maintain a symbolic reference "cvs-head" that points > to the newest git trunk node that's been mirrored to a CVS repository. But is that not just tracking another branch? > Without even considering any other option, I chose to use a lightweight > tag for that purpose, since I have a conceptual view that it's a label I > can move from one referent to another. It strikes me as counter-intuitive > to use a temporary git "branch" that way. Would that even work, removing > it and recreating it all the time? Yes, it would. Remember: a branch in git is just a named ref. It literally used to be a 41-byte file pointing to the tip of the branch in the ancestor graph. And you can update it with git-update-ref. So, a branch in git is very much the movable label you are looking for. Ciao, Dscho - 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