I sometimes lose the target of a tag when editing changesets, but only discover this after pushing. Destructive commands (such as strip and histedit) should warn if the target of tag will be lost, and push should probably sanity check .hgtags as well.
Is there an ill effect visible when this happens?
Bug was inactive for 472 days, archiving
Re-opening as still an issue with 3.3. Most commonly encountered with histedit and rebase - .hgtags is not updated to point to the rewritten changesets. I don't know whether .hgtags should be automatically updated, but history-rewriting commands should at least warn that tags are being lost and offer to update them if not.
Bulk change: standard priority for features is 'wish'.
Bulk move open feature requests to wish priority.
Bug was inactive for 184 days, archiving
Still an issue with 3.6. hg init test cd test echo >a hg add a hg ci -m"a" hg tag a hg tags tip 1:680ccf7f26aa a 0:f1a268e389f6 hg histedit a <change something in a> hg histedit --continue hg tags tip 1:7cb9647fb610 type .hgtags f1a268e389f6d9de43b29f639ffcd61d1fcd7643 a
Ok, adjusting $SUBJECT. Arguably tagged commits should automatically be marked public so they're not subject to editing, but a warning seems reasonable as well.
Ideally history rewriting commands would have an option to move tags to the rewritten changeset.
Bug was inactive for 150 days, archiving
Bug was inactive for 288 days, archiving
Bug was inactive for 151 days, archiving
Fixed by https://mercurial-scm.org/repo/hg/rev/86f0ed7ac688 Navaneeth Suresh <navaneeths1998@gmail.com> histedit: add warning message on editing tagged commits (issue4017) Differential Revision: https://phab.mercurial-scm.org/D5489 (please test the fix)
Bug was set to TESTING for 7 days, resolving