Sean Whitton writes ("Bug#1110996: git-debpush uses version_compare on git tag
names"):
> I think you might have misread the code slightly. Rather than only
> comparing multiple tags on the same commit, the git log command in
> find_last_tag returns all tags *reachable* from $branch_commit, and then
> picks the one with the latest version number.
I don't have time to go and stare at the code again right now, but I
don't believe this can be true.
The existing code will crash if the compare_versions is ever fed a
version number that was extracted from a tag representing an upload
whose Debian version had a ~.
If you are right, that would happen if there were *any* previous ~exp
upload.
I'm not sure why we are digging into the git history so far anyway.
If we want to know what the branch format is *here* at this commit,
why wouldn't we take the gitly-most-recent tag as authoritative?
If the version number ordering is different to the git history graph
ordering [1], and there was a branch format transition in between, we
want the most recent one in git terms, since that's the one which has
the same branch format as the commit we're uploading.
[1] This seems like it could happen if the same package was backported
or the suite was changed or something. Indeed I think we recently did
this with dgit.git: I uploaded +exp1 to experimental, switched the
suite to sid, and uploaded again.
Eg, suppoase the commit graph looks like this:
o HEAD
|
o release, tag: debian/1.0
|
o change branch format
|
o release, tag: debian/1.0+exp1
|
...
We definitely want the format mentioned in the 1.0 tag.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
