jeromekelleher
commented
6 years ago Sounds like a great idea, thanks @ashander. I think a tag format of HDF5_FORMAT_V{major}.{minor} is probably good --- I you create the mapping I'll do the gitting!
Closed ashander closed 6 years ago
jeromekelleher
commented
6 years ago Sounds like a great idea, thanks @ashander. I think a tag format of HDF5_FORMAT_V{major}.{minor} is probably good --- I you create the mapping I'll do the gitting!
ashander
commented
6 years ago Cool. Here's the mapping.txt If everything looks good (see link below for more details including snippets of diffs that correspond to these hashes) I think you can just paste git tag at the start of every line in mapping.txt and source it
More details here including the text files from which I made the mapping : https://github.com/jeromekelleher/msprime/compare/master...ashander:tag-file-format-version?expand=1
jeromekelleher
commented
6 years ago Impressive gitting @ashander! There's a slight issue here, in that we're tagging the first revision that supports a given file format rather than the last. It seems likely that the first revision will have some bugs in it, so perhaps we should change to the last instead? Is there way of capturing this with git?
ashander
commented
6 years ago Thanks! Oh but good point. I guess my map would only work if the last thing you did was change the version. More likely it's the first. If it was always the first thing changed we can use git tag {PREVIOUS VERSION} {SHA}^ on the commits where those lines were changed to get the commit just before the change.
For example: git tag hdf8.0 fc17dbd^ (using a shorter tag format for illustration) will get us
| * | | 5084839 Infrastucture and checks for multi-mutations.
| * | | fc17dbd Added mutation.parent to HDF5 & bumped version.
| * | | 0e655b4 (tag: hdf8.0) Minimal changes to support mutation.parent.
| * | | d59b6be Initial work on fixing simplify sites/mutations.
|/ / /
* | | 299ddc9 Merge pull request #274 from jeromekelleher/final-simplifyDo you think this will work?
Note that even if it does using the hashes in the current mapping.txt won't quite work as there were two intermediate changes. If this seems promising I can add those and provide a new mapping
ashander
commented
6 years ago Oh. Looking at the graph in the previous comment it strikes me that it'd probably be better to get the first commit on master that is parent to a given change to the version lines. My git fu is too weak, currently, to do that
jeromekelleher
commented
6 years ago Oh. Looking at the graph in the previous comment it strikes me that it'd probably be better to get the first commit on master that is parent to a given change to the version lines. My git fu is too weak, currently, to do that
Yes, what we really want is the parent of the commit where this hash was merged. What bout using git log --merges to find the merge commit where the commit you've found from git blame was merged, and then take the other parent? This should give the last state of master just before the HDF5 version was changed. (I definitely wouldn't have partial implementations of a HDF5 version on master).
ashander
commented
6 years ago Ah nice. I think git log --merges on the commit that changes the HDF5 version will give the last commit on master. Not sure what the bit about 'take the other parent' means but don't think it's needed? I've pushed an update that uses that approach and sourcing mapping.txt
... results in these tags:
jeromekelleher
commented
6 years ago I've hit an annoying snag with this plan unfortunately. The issue is that setuptools_scm expects all tags to be for versions, and will break when it hits (what it considers to be) a malformed version. This means that we can check out these tags, but then we can't actually build them (which is useless).
I think the best option is to put a "Revision history" section into the [http://msprime.readthedocs.io/en/stable/file-format.html](file format section) of the docs, and put the mapping you've derived into a table there, along with a quick explanation of what is it and what it's for. What do you think @ashander?
jeromekelleher
commented
6 years ago Version 9 should go in as e504abd3a44d7da23bc0ffca3fa23671454ff720
ashander
commented
6 years ago On Mon, Dec 11, 2017 at 05:13 Jerome Kelleher notifications@github.com wrote:
I've hit an annoying snag with this plan unfortunately. The issue is that setuptools_scm expects all tags to be for versions, and will break when it hits (what it considers to be) a malformed version. This means that we can check out these tags, but then we can't actually build them (which is useless).
Ah that is annoying!
I think the best option is to put a "Revision history" section into the [ http://msprime.readthedocs.io/en/stable/file-format.html](file format section) of the docs, and put the mapping you've derived into a table there, along with a quick explanation of what is it and what it's for. What do you think @ashander https://github.com/ashander?
Sounds good I can change my branch accordingly
—
You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeromekelleher/msprime/issues/325#issuecomment-350720464, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfLOLhoq6iNBEozaq-2n052ND0mAGeVks5s_SpkgaJpZM4Q4V-g .
-- -Jaime
jeromekelleher
commented
6 years ago Closed in #326
If we can figure out a format for the tag so that it doesn't clash with the actual program version numbers, maybe this is a good idea? I'm happy to compile a list mapping commit hashes to file format versions.
As discussed in #322