https://bz.mercurial-scm.org/show_bug.cgi?id=6220
Bug ID: 6220
Summary: [hg/python3] pre-tag hook can't fixup arguments
anymore
Product: Mercurial
Version: unspecified
Hardware: PC
OS: Linux
Status: UNCONFIRMED
Severity: feature
Priority: wish
Component: Mercurial
Assignee: bugzi...@mercurial-scm.org
Reporter: marcin.kasper...@mekk.waw.pl
CC: mercurial-devel@mercurial-scm.org
Python Version: 3.7
(background: I am porting my extensions so they work on py3 Mercurials, mostly
I succeeded but this seems to be a difficult obstacle)
It looks like py3 Mercurial's no longer allow pre-tag hook to fixup hg tag
arguments, at least some of them. My pre-tag hook changes value of b'rev'
option, on python2 it works as expected and impacts the command behaviour, on
python3 it is ignored. I suspect this is side-effect of some byteskwargs here
or there, but I am not sure.
Wider details: I faced this while porting
https://bitbucket.org/Mekk/mercurial-update_version/ to python3. This extension
solves nuisance of maintaining various VERSION constants around the code by
installing pre-tag hook which - whenever you do hg tag - extracts actual
version number from the tag, scans sources for version constants, updates those
constants, commits the change, and only then actually allows hg tag to do its
work.
In normal case (hg tag 1.2.3) it is ported and works as expected, but there is
special case of tab by revision, like
hg tag -r bf56d726edc9577b65d6063b831bd6d4c4afc98 1.2.3
The case is important as this is what TortoiseHG does under the hood when one
clicks tagging in it's interface.
I mostly give up while sb is tagging by revision, but try to do my work when
given revision matches current directory revision as then the command is
actually equivalent to hg tag 1.2.3 (and, as I said, this is what TortoiseHg
issues, so handling it is the only option to keep supporting TortoiseHg users).
But in such a case I wish to tag my version fixup commit, not the original one.
So I simply change opts[b'rev'] to None to get Mercurial tagging current
working dir repo instead of tagging bf56d726edc9577b65d6063b831bd6d4c4afc98.
Under python2 it works nicely, actual tag command uses fixed opts['rev'] and my
commit is tagged.
Under python3 it looks like my change is ignored, and original 'rev' is used
while tagging.
Tox report (all failures are caused by the test which verifies this very
behaviour, that fixed up commit is tagged, not the original one):
ERROR: py35-hg52: commands failed
ERROR: py35-hg51: commands failed
ERROR: py35-hg50: commands failed
ERROR: py36-hg52: commands failed
ERROR: py36-hg51: commands failed
ERROR: py36-hg50: commands failed
ERROR: py37-hg52: commands failed
ERROR: py37-hg51: commands failed
ERROR: py37-hg50: commands failed
py27-hg52: commands succeeded
py27-hg51: commands succeeded
py27-hg50: commands succeeded
py27-hg49: commands succeeded
py27-hg48: commands succeeded
py27-hg45: commands succeeded
py27-hg44: commands succeeded
py27-hg41: commands succeeded
py27-hg38: commands succeeded
py27-hg37: commands succeeded
py27-hg33: commands succeeded
py27-hg30: commands succeeded
py27-hg29: commands succeeded
py27-hg27: commands succeeded
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I suppose there can be more problems like this. In general I treat it as
breaking hook protocol in some way – pre-hooks were always able to fixup
command arguments, and this was very useful feature.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
