Does it really make sense for that first example to fail, though? "git tag hello v1.9.5" is an idempotent operation, isn't it? The second attempt is a no-op? If "git tag ..." simply does nothing if the tag already exists (as requested) then that would make the OP's issue go away: only the 2nd example would fail. On Mon, Jun 9, 2025 at 11:45 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > M Hickford <mirth.hickford@xxxxxxxxx> writes: > > > Hi. Presently, the error "tag ... already exists" doesn't distinguish > > between tagging the same commit or a different commit: > > > > >git tag hello v1.9.5 > > > > >git tag hello v1.9.5 > > fatal: tag 'hello' already exists > > > > >git tag hello v2.0.0 > > fatal: tag 'hello' already exists > > > > To inform the user, it would be nice to distinguish these cases, perhaps: > > > > >git tag hello v1.9.5 > > fatal: tag 'hello' already exists pointing at > > d4e6038a068d0aecd5ec28c83afbfc6d4903092f > > > > >git tag hello v2.0.0 > > fatal: tag 'hello' already exists but points at > > 18a07354e33f86c8349ffdc300d9087876658264 > > > > The second error is typically more concerning than the first. > > > > What do you think? > > Not interested. When the user gets that "fatal" message, the > existing tag did not get modified, so they can just do whatever > check they want (like "git range-diff v1.9.5...hello") themselves. > > Besides, in the above examples, is d4e6038a something the user > immediately recognises as the same as v1.9.5 or the object existing > v1.9.5 tag points at? I somehow doubt it. So after getting the > error, there needs some digging to figure out how v1.9.5 and > existing hello are related to each other _anyway_, I would think. > > >
