Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identify repository versions #3

Open
nxg opened this issue Aug 27, 2013 · 3 comments
Open

Identify repository versions #3

nxg opened this issue Aug 27, 2013 · 3 comments
Labels

Comments

@nxg
Copy link
Collaborator

nxg commented Aug 27, 2013

This is a log of an email discussion.

Norman: It could get confusing to have multiple versions of this mn2e.bst
knocking around. Can you think of an easy way of getting a changeset
checksum into the file? One way would be to move mn2e.bst to mn2e.bst.in,
edit the latter to the former with a bit of sed magic in a Makefile, and
somehow indicate that it's the resulting file that should be used. But
that's messy. Another possibility is to create a little distribution
tarball with a README and the .bst file, with the checksum edited into it
at that point -- I presume github can host that.

Tim: We can put version numbers in. (the history is already kept up to date in
that file). I'd prefer it if no Makefile was required so that people can
download it directly from the style file.


A possible resolution is to use the ident attribute in gitattributes, as described in this stackoverflow answer. I've never done this myself, but it sounds as if this is the right sort of solution for this particular case, where we're anticipating the mn2e.bst file being deployed right out of the repository, rather than through a release process (which would be over the top for this case).

How does this sound?

@timj
Copy link
Owner

timj commented Aug 27, 2013

Sounds like it should work. Just shove a $Id$ in the prologue somewhere?

timj added a commit that referenced this issue Aug 29, 2013
We would like to make sure that we can work out what version people
are downloading without necessarily having to put in explicit version
numbers. We do attempt to update the HISTORY field when we make changes
but in addition we now use a ident git attribute to automatically
embed the SHA1 in the file when it is checked out.

This fixes issue #3
@timj
Copy link
Owner

timj commented Aug 29, 2013

@nxg Gitattributes seem to work for clones but the github view of the BST file does not include the expansion so it doesn't actually help us and people will still by default pick up the version from github without the SHA1.

@nxg
Copy link
Collaborator Author

nxg commented Aug 29, 2013

...if people insist on downloading it directly from github. Good point.

Perhaps this does enhance the case for distributing the .bst file from CTAN, since doing so is a natural point for a (pretty trivial) 'release' step which could bake the checksum into the .bst on the fly. Anyone who desperately wants to use the github version could be told, in the README, to do so from a clone rather than just downloading from the github web interface.

I know from experience that uploading to CTAN is pretty streamlined, and would simply require a note in the upload form saying "replace path macros/latex/contrib/mnras/mn2e.bst – by arrangement with MNRAS maintainers"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants